On 9 March 2016 at 07:53, David Woodhouse <dw...@infradead.org> wrote: > 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. >
So that means merging master into the topic branch before merging the topic branch into master? >> 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. > I am not saying there is anything wrong with it, but linear history is inherently simpler to understand while browsing through the commit history imo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
