On Wed, Oct 10, 2012 at 09:31:55PM -0500, Ben Myers wrote: > Hey Dave, > > 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. 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 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. :/ Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
