Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
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.
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. Suppose you have this history:
.---x---x---x
/
.---A---B
/
---0---o---o---A'--B'--C'--D'
\
o---o---A''-B''-C''-D''-E''
Originally your upstream had 0---A---B; you built your 'x' on
top of it. Then the upstream rebases and publishes history that
leads to D' (i.e. A and B are rewritten). Later, the history is
further rewritten and E'' is the latest upstream tip.
If you haven't done "git fetch" since you started building on
top of B, refs/remotes/ will still say B and using B as base
(and E'' as onto) will give you the right rebase. Earlier, we
did not use B in the rebase in any way, so your patch is
definitely an improvement.
However, if you have run "git fetch" (say, to peek what the
upstream has been up to), your refs/remote/ may say D'. Using
that as the base and rebasing onto E'' is not quite optimal,
isn't it?
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 do not mean this comment makes your approach invalid, though.
It is a start in the good direction.
-
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
