Re: [PATCHv4 3/4] t5520-pull: --rebase with rebased upstream and two branches

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 11, 2009, 23:19 UTC
Message-ID: <7vhbymfjev.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1244759961-4750-4-git-send-email-santi@agolina.net>

Santi Béjar <santi@agolina.net> writes:

Show 7 quoted lines

> If you have two branches tracking an upstream that is rebased,
> currently you have to do:
>
> git checkout branch1
> git pull --rebase remote branch
> git checkout branch2
> git pull --rebase remote branch

I think the "ah, I see it rebased" computation is done at a wrong place for the above to work. You do not even have to do two pull--rebase; I think you can simply do "git fetch; git pull --rebase" to break it.

My understanding of the current code we have since c85c7927 is that it was done as a quick-and-dirty hack that is merely good enough for CVS style history where everybody is linear. Grabbing where it used to be last time we looked at before the fetch, and assuming it is the correct original fork point, will never work, if you updated the remote tracking ref outside of the current invocation of "pull --rebase" (if everybody is linear, you by definition have one single branch, so in that special case, the hack may happen to work, if you do not fetch).

If you want to fix this, I think you need to use the knowledge of where the tip of remote/$origin/$branch used to be. That is kept in the reflog of that remote tracking ref. So perhaps

 (0) Lose "oldremoteref=..." before "git fetch" happens in git-pull.sh;

 (1) just before "exec git-rebase", check rtb@{1} is an ancestor of rtb,
     if so be happy;

 (2) otherwise, in the same place, for some (hopefully small) posint n,
     see if rtb@{n} is an ancestor of rtb; use that as the "oldremoteref"
     when invoking "git-rebase".

where rtb == remote tracking branch.