This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Procedure for Patches Merging FreeBSD Code
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