Re: Procedure for Patches Merging FreeBSD Code

[Joel Sherrill <joel.sherrill@oarcorp.com>]

On 7/26/2017 2:43 PM, Corinna Vinschen wrote:
> On Jul 26 09:59, Joel Sherrill wrote:
>> Hi
>>
>> Gedare, Aditya, and I were discussing that it is useful
>> during development to have a git branch with a patch
>> series that adds the unmodified FreeBSD files followed
>> by a patch series that adds them to the build system
>> and makes them work. Then you can easily review the
>> differences against the original source.
>>
>> Would it be desirable for patches submitted to newlib
>> to follow this pattern? Or should Aditya submit a
>> single patch series including the addition and
>> any modifications?
>>
>> For sure, the addition change can only add the source
>> files and not touch the build system. Otherwise
>> git bisect will break. That can't be allowed if
>> avoidable.
> 
> We don't support merges in the newlib-cygwin repo, just the same as in
> the binutils-gdb repo.  All changes must be part of a linear history.
> The post-receive hook will refuse merges.
> 
> You can create branches, but they have a disjunct history and you'd
> have to cherry-pick from there for master, so it's not much of an
> advantage for the person applying the patches.

I wasn't concerned about this. Managing the work is a local
user issue. It has to be patches sent to the mailing list. :)
> 
> Nothing speaks against providing a two step patchset, first including
> the original file into newlib, then a second patch adding the newlib
> required changes on top.  We can do this as part of the normal review
> process.

If you are OK with it, I personally like doing this because it
encourages and aids in tracking differences from the upstream.

Awesome!

--joel

> Corinna
>