Re: nicer frontend to get rebased tree?

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Aug 23, 2008, 22:13 UTC
Message-ID: <20080823221324.GA18472@atjola.homenet>
In-Reply-To: <alpine.LFD.1.10.0808231440530.3363@nehalem.linux-foundation.org>

On 2008.08.23 14:52:37 -0700, Linus Torvalds wrote:

Show 35 quoted lines

> On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:
> >
> > you got nice and detailed answers,  for example you can track a
> > rebased tree in your working directory using git pull --rebase.
> > What's wrong with that?
> 
> No, you really really cannot do that.
> 
> If the _tree_ you are tracking is itself rebasing (not just your own 
> tree), then you cannot and absolutely SHOULD NOT use rebase (not directly, 
> and not with "git pull --rebase".
> 
> Why?
> 
> Let's look at what happens. Let's say that your history looks like
> 
> 	... -> A -> B -> C -> a -> b -> c
> 
> where the upper-case letters are from the tree you track, and the 
> lower-case letters are the commits you added yourself.
> 
> Now, let's say that the tree you track gets rebased, and in the process 
> 'B' is removed (because it turns out it was buggy), and A and C get 
> modified. What happens?
> 
> You now have
> 
> 	... -> A -> B -> C -> a -> b -> c     <- your branch
> 	  \
> 	    other stuff -> A' -> C'     <- newly rebased branch
> 
> (where "other stuff" is whatever the remote branch was rebased on top 
> of) and when you now try to rebase your stuff on top of the newly rebased 
> branch, you are going to end up trying to rebase all the _old_ commits 
> that weren't even yours (ie it's going to try to rebase A, B and C too!)

But before the fetch step, you have remote/branch point to your old upstream. If "pull --rebase" remembers that and uses:

git rebase --onto remote/branch $old_upstream

That should work. And in fact, it actually seems to do that.

	exec git-rebase $strategy_args --onto $merge_head \
	${oldremoteref:-$merge_head}

With $oldremoteref being the remote tracking branch before the rebase.

That said, it seems very fragile. One "git fetch" and your upstream is lost and the next "pull --rebase" will fail.

So a somewhat less fragile way to do it would be:

git checkout -b foo origin/foo git branch foo-upstream .... git fetch origin git rebase --onto origin/foo foo-upstream git branch -f foo-upstream origin/foo

So that you always have the current upstream for your branch available and can thus do a correct rebase. That at least doesn't break on its own, but still does when you forget to adjust your upstream reference.

I don't actually like the idea, but maybe a refs/upstreams namespace could be used by some script to keep track of the current upstreams of local branches and to help with such a workflow, if one really badly wants to do that... *hides*

Björn