Hey Dave, On Thu, Oct 11, 2012 at 04:03:15PM +1100, Dave Chinner wrote: > On Wed, Oct 10, 2012 at 09:31:55PM -0500, Ben Myers wrote: > > On Mon, Oct 08, 2012 at 05:39:21PM -0500, Ben Myers wrote: > > > On Mon, Oct 08, 2012 at 09:55:58PM +1100, Dave Chinner wrote: > > > > Hopefully the final version. > > > > > > I am testing this new rev now... My v4 run over the weekend crashed but > > > unfortunately I wasn't able to get a stack trace. We'll see what shakes out. > > > > I'm still not sure what happened with the v4 run I mentioned. Subsequent > > testing has shown this series to be solid with the new changes. It is ready to > > go. > > > > However, pulling this in right now will result in a merge commit from the > > upstream tree to ours later in the rc1 merge. My understanding is that if > > Linus were to subsequently pull from our tree, the merge commit would cause > > some ugliness in upstream commit history. See: > > > > http://oss.sgi.com/archives/xfs/2009-04/msg00014.html > > > I'm not sure that's relevant. The problem ther was this sort of > behaviour: > > - merge mainline into XFS tree. > - commit XFS stuff > - merge mainline into XFS tree > - commit XFS stuff > ..... > - merge mainline into XFS tree > - commit XFS stuff > - pull request > - merge mainline into XFS tree > - commit XFS stuff > <loop> > > And so the changes in the XFS tree where not easy to discern from > the changes pull in from mainline. Indeed, look at the pull request > to see exactly waht Linus was complaining about: > > http://oss.sgi.com/archives/xfs/2009-04/msg00009.html > > Felix Blyakher (25): > Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs > [XFS] Warn on transaction in flight on read-only remount > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > xfs: Update maintainers > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Revert "[XFS] use scalable vmap API" > Revert "[XFS] remove old vmap cache" > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Fix xfs debug build breakage by pushing xfs_error.h after > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > xfs: increase the maximum number of supported ACL entries > Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Revert "xfs: increase the maximum number of supported ACL entries" > > This is the mess that Linus was complaining about - not about a > single merge per release that is used to keep the tree tracking > mainlinei having a conflict in it. Yowza. That is ugly. > Having a dev tree history something like: > > - commit XFS stuff > - commit XFS stuff > - merge -rc1 from mainline > - commit XFS stuff > - commit XFS stuff > - commit XFS stuff > ...... > - commit XFS stuff > - pull request > - commit XFS stuff > - commit XFS stuff > <loop per release> > > Isn't really the problem that Linus was talking about. Indeed, one > mainline merge per release is pretty much as expected, especially if > you have a tree that you do not rebase that is consistently > committed to.... I see what you mean. The current situation where we always fast-forward to -rc1 is still much cleaner than that in terms of history. The problem could also be solved with a topic branch for the duration of the merge window. There is some more insteresting discussion here: http://lwn.net/Articles/328438/ I'll quote from Linus's email: "And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do." If we can abide by that by using topic branches instead of pulling work into the master branch during the merge window I think it would be clearer in terms of history. I'd really like to sync up on -rc1 without making a mess each time. More topic branches would probably be good for us anyway. Maybe that is something we can experiment with. This link was also kind of interesting reading: http://yarchive.net/comp/linux/git_merges_from_upstream.html > > I haven't found a way around this, so that's why we're waiting until after the > > -rc1 fast-forward to pull this in. > > Merges by themselves aren't bad - it's excessive, unnecessary > use of them that causes problems. :/ Yep, I gather that I misunderstood the issue with that pull request. Thanks, Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
