XFS Master Branch Rebase

XFS Master Branch Rebase

[Alex Elder]

Some recent commits have resulted in changes to
the XFS master branch that result in non-trivial
merges, which are not something we want to have in
our git history.  (I didn't realize this when I
pushed my last set of updates out, unfortunately.)

To remedy this, I'm have re-based the XFS master
branch on oss.sgi.com against v2.6.35-rc6.

This is important to you if you currently have
a git tree tracking this branch in the XFS
repository, because doing a typical "git pull"
won't produce in the desired result.

Instead, you should issue a command like one
of the following to update your private branch.

If your branch "xfs-master" tracks branch "master"
at git://oss.sgi.com/xfs/xfs.git, and you now
have "xfs-master" checked out, you can do this:
    git pull --rebase -f

If you have a different branch checked out, you
can do this instead to force the re-based commits
to land in your "xfs-master" branch:
    git pull git://oss.sgi.com/xfs/xfs.git +master:xfs-master

Another way to get a current branch to line up with
the newly re-based XFS master branch is  to reset
it to an earlier commit (such as v2.6.35-rc5) and
follow that with a "git pull" command:
    git reset --hard v2.6.35-rc5
    git pull git://oss.sgi.com/xfs/xfs.git master

					-Alex

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Master Branch Rebase

[Dave Chinner]

On Tue, Jul 27, 2010 at 11:16:06AM -0500, Alex Elder wrote:
> Some recent commits have resulted in changes to
> the XFS master branch that result in non-trivial
> merges, which are not something we want to have in
> our git history.  (I didn't realize this when I
> pushed my last set of updates out, unfortunately.)
> 
> To remedy this, I'm have re-based the XFS master
> branch on oss.sgi.com against v2.6.35-rc6.

<groan>

Alex, this is a bit annoying. Rebases are a real pain for anyone
downstream that is using git in non-trivial ways. I'll give you an
idea of what this means to me - for the xfs tree directly:

	- bare repository on kernel.org I have to fix
	- local bare repo pulled from kernel.org I have to fix
	- local working repo I have to fix with about 10 separate
	  working branches that I have now have to rebase
	- run garbage collection on all repos

And for the for-2.6.36 branch of my xfsdev.git tree on kernel.org
(which I've been careful not to require rebasing as the OSS tree has
gained more commits):

	- all the commits in that branch are stale, so the branch
	  has to be destroyed (in 3 repos)
	- remove any branch based on for-2.6.36 in 2 bare repos
	- recreate a new branch and pull the new xfs tree commits
	  into it and push it back out to bare repos
	- rebase another ~10 local working branches based on the
	  for-2.6.36 branch and push them back out
	- restage all the pending commits that I hadn't pushed out
	  on that branch yet.
	- run garbage collection on all repos

And to top that all off - I know that people have pulled branches
from this tree that are based on for-2.6.36, so they are going to
get problems when trying to update them again. i.e. an upstream
rebase triggers problems for users downstream of my repo, not just
the direct downstream of the OSS repo....

....

> If you have a different branch checked out, you
> can do this instead to force the re-based commits
> to land in your "xfs-master" branch:
>     git pull git://oss.sgi.com/xfs/xfs.git +master:xfs-master

You don't want to do this - the forced merge causes a branch in
history in the local repository and hence it's no longer an
identical copy of the upstream repository any more. I got caught by
this on a previous rebase when I started pushing commits back out
and people tried to pull them...

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Master Branch Rebase

[Christoph Hellwig]

On Wed, Jul 28, 2010 at 09:27:19AM +1000, Dave Chinner wrote:
> Alex, this is a bit annoying. Rebases are a real pain for anyone
> downstream that is using git in non-trivial ways.

FYI: I asked Alex to do it, so I'll happily take all the blaim here.

The real problem is that we had quite a merge mess before, which Linus
absolutely doesn't like.  And if I traced it back correctly most of
it actually came from the xfsdev tree.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Master Branch Rebase

[Dave Chinner]

On Wed, Jul 28, 2010 at 04:44:00AM -0400, Christoph Hellwig wrote:
> On Wed, Jul 28, 2010 at 09:27:19AM +1000, Dave Chinner wrote:
> > Alex, this is a bit annoying. Rebases are a real pain for anyone
> > downstream that is using git in non-trivial ways.
> 
> FYI: I asked Alex to do it, so I'll happily take all the blaim here.

No blame - just pointing out the consequences (again).

> The real problem is that we had quite a merge mess before, which Linus
> absolutely doesn't like.  And if I traced it back correctly most of
> it actually came from the xfsdev tree.

If you call a single merge of 2.6.35-rc6 back into the for-2.6.36
branch a "merge mess", then I'm guilty as charged.  However (and it
is a *BIG* however), I haven't asked Alex to pull from that tree
and upstream should not be pulling from downstream trees without a
specific request to do so.

I'm maintaining that whole tree for _my_ benefit - I need a
mainline-based tree that also contains all the non-mainline XFS
commits, and I need to be able to update them independently.  Just
because the tree contains a branch named "for-2.6.36" and has XFS
commits that are not yet upstream doesn't mean the branch is a
upstream pull target.

Alex, if you want to pull from my tree rather that commit all the
patches to the main XFS tree yourself, tell me so I can cherry-pick
the commits into a clean, pristine branch and send a pull request.
That way this whole problem just goes away...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Master Branch Rebase

[Christoph Hellwig]

On Wed, Jul 28, 2010 at 09:09:54PM +1000, Dave Chinner wrote:
> If you call a single merge of 2.6.35-rc6 back into the for-2.6.36
> branch a "merge mess", then I'm guilty as charged.  However (and it
> is a *BIG* however),

It wasn't that simple.  We had a few unclean merges from mainline and
from for-linux to for-2.6.36 or similar branches.

> I haven't asked Alex to pull from that tree
> and upstream should not be pulling from downstream trees without a
> specific request to do so.
> 
> I'm maintaining that whole tree for _my_ benefit - I need a
> mainline-based tree that also contains all the non-mainline XFS
> commits, and I need to be able to update them independently.  Just
> because the tree contains a branch named "for-2.6.36" and has XFS
> commits that are not yet upstream doesn't mean the branch is a
> upstream pull target.

Yeah.  The normal way to maintain a development branch is to stay
is to never pull in mainline into an existing branch.  If we absolutely
need to update to a newer version from Linus' tree it should be rebased
ontop of it.  Unfortunately we'll need to do this once in a while
for something like XFS which has rather complex interactions with core
VM and VFS changes, so expecting the xfs development branch to be
a stable target is not generally a good idea.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Master Branch Rebase

[Alex Elder]

On Wed, 2010-07-28 at 21:09 +1000, Dave Chinner wrote:
> On Wed, Jul 28, 2010 at 04:44:00AM -0400, Christoph Hellwig wrote:
> > On Wed, Jul 28, 2010 at 09:27:19AM +1000, Dave Chinner wrote:
> > > Alex, this is a bit annoying. Rebases are a real pain for anyone
> > > downstream that is using git in non-trivial ways.
> > 
> > FYI: I asked Alex to do it, so I'll happily take all the blaim here.
> 
> No blame - just pointing out the consequences (again).
> 
> > The real problem is that we had quite a merge mess before, which Linus
> > absolutely doesn't like.  And if I traced it back correctly most of
> > it actually came from the xfsdev tree.
> 
> If you call a single merge of 2.6.35-rc6 back into the for-2.6.36
> branch a "merge mess", then I'm guilty as charged.  However (and it
> is a *BIG* however), I haven't asked Alex to pull from that tree
> and upstream should not be pulling from downstream trees without a
> specific request to do so.

I trusted Christoph's judgement about whether it was a "mess"
or not.  He suggested the re-base, and I agreed to do it.

> I'm maintaining that whole tree for _my_ benefit - I need a
> mainline-based tree that also contains all the non-mainline XFS
> commits, and I need to be able to update them independently.  Just
> because the tree contains a branch named "for-2.6.36" and has XFS
> commits that are not yet upstream doesn't mean the branch is a
> upstream pull target.
> 
> Alex, if you want to pull from my tree rather that commit all the
> patches to the main XFS tree yourself, tell me so I can cherry-pick
> the commits into a clean, pristine branch and send a pull request.
> That way this whole problem just goes away...

Ironically, one of the reasons I wanted to pull from your branch was
to avoid any chance of being in conflict with any of the work you
had already done.  In any case, before I did so, I reached you on
IRC, and there you said that if I had in my branch "already merged
in 2.6.36-rc6, then the for-2.6.36 branch in my tree should just
pull right in...."  I took that as at least a consent to pull
from that branch (which I did).

I normally take in all patches from mail (or patchwork).  You
seem to want me to do things differently--to wait until you
have committed it to your git tree and then requested I pull
it.  All that's fine, but in some cases I've felt like there
was some ambiguity.  Regardless, I won't pull from your tree
unless I have communicated with you about it.

					-Alex

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS Master Branch Rebase

[Alex Elder]

On Wed, 2010-07-28 at 09:27 +1000, Dave Chinner wrote:
> On Tue, Jul 27, 2010 at 11:16:06AM -0500, Alex Elder wrote:
> > Some recent commits have resulted in changes to
> > the XFS master branch that result in non-trivial
> > merges, which are not something we want to have in
> > our git history.  (I didn't realize this when I
> > pushed my last set of updates out, unfortunately.)
> > 
> > To remedy this, I'm have re-based the XFS master
> > branch on oss.sgi.com against v2.6.35-rc6.
> 
> <groan>
> 
> Alex, this is a bit annoying. Rebases are a real pain for anyone
> downstream that is using git in non-trivial ways. I'll give you an
> idea of what this means to me - for the xfs tree directly:

I'm not going to argue, I know it's bad.  I'll try to offer
a little explanation though.

Christoph told me that Linus dislikes non-trivial merges,
and suggested I re-base the tree.  I have been trying to
avoid having this sort of effect on people using the
repository.  But I opted in this case to upset them
(and you) rather than Linus, and went to work re-basing
things.

. . .
> > If you have a different branch checked out, you
> > can do this instead to force the re-based commits
> > to land in your "xfs-master" branch:
> >     git pull git://oss.sgi.com/xfs/xfs.git +master:xfs-master
> 
> You don't want to do this - the forced merge causes a branch in
> history in the local repository and hence it's no longer an
> identical copy of the upstream repository any more. I got caught by
> this on a previous rebase when I started pushing commits back out
> and people tried to pull them...

The "+" in the refspec on the command above is there
intentionally, to make the local branch "xfs-master"
to be updated to match the remote *without* doing a merge.
If my local "xfs-master" branch is at the previous head
for "master", it works for me.

With that refspec, the "git fetch" part of the pull
does the forced update; the "git merge" part of the
pull should then find the branch "Already up-to-date."

					-Alex


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs