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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
