This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |