Procedure for Patches Merging FreeBSD Code

[Corinna Vinschen]

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.

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170726/1af8873b/attachment.sig>