Re: [PATCH] pull --rebase: be cleverer with rebased upstream branches

Hi,

On Sat, 26 Jan 2008, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

When the upstream branch is tracked, we can detect if that branch was 
rebased since it was last fetched.  Teach git to use that information 
to rebase from the old remote head onto the new remote head.

This is certainly nicer than the original (which is not in 1.5.3, so 
even this late in the cycle it is "fixing up a new feature we will be 
introducing in 1.5.4" category that I will apply).  But I think a bit of 
caution and perhaps an illustration or two in the doucmentation would 
help.

Well, I half expected it to be post-1.5.4.

If you do "git fetch" from the origin since the last time you ran "pull 
--rebase" for the remote, we will have the same issue.

Yes, that occurred to me, too.

So it might make sense to make the logic to figure out B, given
your local history that leads from 0 to x's (and nothing else),
a bit cleverer than looking at the tracking branch.  We can look
at reflog for example.  "git log -g --pretty=oneline" may have
entries of this form:

    * branch: Created from B
    * rebase finished <branch> onto B

and the latest (i.e. younguest) entry is where the part of your current 
history to be rebased (i.e. base commit) starts.  This is much more 
reliable than looking at the tracking branch, whose answer may or may 
not match B at all.

I did not want to do that, because it is quite possible that the reflogs 
were disabled, or that the relevant reflogs were already expired.

However, I think that it might be a good approach to try reflogs first, 
and fallback to what I sent if there are no reflogs (or if it is detected 
that the reflog entry is not possibly the correct one, since what was 
rebased to is no longer an ancestor of the current branch).

Ciao,
Dscho