Re: nicer frontend to get rebased tree?

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.08.23 14:52:37 -0700, Linus Torvalds wrote:
> 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