Santi Béjar <santi@xxxxxxxxxxx> writes:
> 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.
--
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