On Wed, 2016-03-09 at 07:49 +0700, Ard Biesheuvel wrote: > > I agree that they should be allowed, but i share the concern that > merging puts the burden of fixing up conflicts on the maintainer > rather than the contributor, who is arguably in a worse position to > assess any potential problems on a seemingly clean merge, especially > since merges are much more forgiving than rebases.
For a not-yet-proficient maintainer to ask a submitter to perform the merge for themselves, or to verify the result of a merge, seems reasonable. > On top of that, the current crop of Tianocore committers is not > entirely on top of things yet as fas as git is concerned, and having > non-linear history just because someone couldn't be bothered to do a > pull beforehand should also be avoided imo. Nah, history that is trivially non-linear is fine. There's absolutely no harm in it. Even for backporting to SVN it's easy enough; you just take a line through it which represents the state of the upstream tree at any given time. Thus collapsing the merge commits into a single SVN commit. But nobody cares because that's no worse than what SVN made people do anyway. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
