STM32H7 HAL update, merge ready.

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Mar 10 15:10:21 UTC 2022


On 10/03/2022 15:24, Karel Gardas wrote:
> On 3/10/22 15:06, Sebastian Huber wrote:
>>> So, the only way out of the chaos was to:
>>>
>>> 1) replace all HAL files with new files
>>
>> Yes, this is fine, but if all the new files have now UNIX line endings 
>> why didn't you change the existing files to UNIX line endings before 
>> the update? I guess you copied the files from a Git repository. Can't 
>> you first change the existing files to UNIX line endings and make a 
>> commit. Then copy the files from your upstream Git repository.
> 
> Honestly, I've tried that IIRC, but result was that the diff was still 
> not right. I investigated at that time and found out that there were 
> file(s) (few) which were using mixed line encoding at that time. E.g. 
> someone edited LF file with CRLF editor and then file was using LF + 
> CRLF on edited lines. Something like that.

I converted the files to UNIX line endings using:

dos2unix `find -type f `

https://github.com/sebhub/rtems/tree/stm32h7-unix-line-endings

I can't rebase your branch on top if it, however, from the looking at 
the merge conflicts it is clear that the individual files are related.

> 
> So the pain of dealing with this mess was so high and unnecessary since 
> those were HAL files anyway that I changed the approach to just simply 
> replace the files.

Replacing the files is fine, but please copy them on top of the original 
files converted to UNIX line endings. Do you still have a checkout of 
the STM Git repository available to copy the files again?

> 
> If you would like to review changes in HAL files, then you may diff 
> original merged projects files. They both are on github.com so you can 
> investigate either there or on local copy. But this is HAL code, 
> something STMicro provided and I don't see any point in dealing with 
> that -- unless there is some bug to report...

It is quite likely that this update breaks something and a reviewable 
history could help here. Another option would be to do the updates in 
smaller steps so that a git bisect is more effective.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


More information about the devel mailing list