[PATCH] rebase: be cleverer with rebased upstream branches

Since c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26), 'git pull --rebase' has used the reflog to try to rebase from the old upstream onto the new upstream.

However, if, instead of 'git pull --rebase', the user were to do 'git fetch' followed by 'git rebase', the reflog would not be walked. This patch teaches "git rebase" the same reflog-walking tricks that 'git pull --rebase' already knows.

This may be useful for rebasing one branch against another local branch that has been rebased. Currently, you would have to do that using 'git rebase --onto' or by configuring it on the branch.

It might seem like most of the related code in git-pull.sh can be removed once git-rebase.sh supports reflog walking. Unfortunately, not much of it can be removed, though. The reason is that git-pull.sh simulates one step of "reflog walking" by keeping track of the position of the remote-tracking branch before and after the fetch operation. This does not rely on reflogs. There are at least two cases where the reflog is not used: a) when it is disabled, b) when the remote branch was specified on the command line (as in 'git pull --rebase origin master'). In both of these cases, git-pull.sh remembers the position of the reference before the fetch and uses that as a kind of '$upstream@{1}'.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
    This applies on top of mz/rebase.

    I have been using this in combination with the patch for defaulting
    rebase to @{upstream} for a few months now. I find it very convenient
    e.g. when Junio has published some changes and I want to rebase my
    branches. Then I just go to each of my branches and run 'git rebase'
    without any arguments, and they get rebased correctly, whether they
    are based on origin/master, origin/pu (they shouldn't be, but let's
    say they are anyway), or on a local branch that is in turn based on
    e.g. origin/master.

    HOWEVER, this causes a very noticable delay in some cases. With this
    patch, 'git rebase' walks the reflog of the upstream ref until it
    finds a commit that the branch-to-rebase contains. If the upstream ref
    has moved a lot since the branch was last rebased, there may be quite
    a few commits to test before the old upstream commit is found.

    The same thing can already occur with 'git pull --rebase' for exactly
    the same reasons. For example, assume that your upstream remote branch
    changes quite frequently and that you often fetch from the remote so
    that your origin/master gets a long reflog. If you then checkout some
    branch you had not been working on for a while, and run 'git pull',
    you get into the same situation. The delay is probably less likely to
    be noticed in the case of 'git pull --rebase', however, since most
    users will probably assume it is a problem with the network or the
    server.

    Of course, 'git pull --rebase' can also be used with a local branch
    configured as upstream. In this case, the behavior today is just like
    what this patch introduces for 'git rebase'.

    What do you think? I think it's a useful feature, but how do we handle
    the delay problem? Maybe simply by making it configurable?

    Should such a configuration variable apply to 'git pull --rebase' as
    well? It would seem inconsistent otherwise, but maybe that's ok since
    'git pull --rebase' is usually used with remote-tracking branches,
    which probably change less frequently. Btw, is this a correct
    assumption? It is definitely true for my own work on git, but I
    actually think it's the other way around for my work at $dayjob. Am I
    missing some part to the puzzle that explains why I had not noticed
    the delay until I started using this patch?

 Documentation/git-rebase.txt |    7 ++++++-
 git-rebase.sh                |   13 +++++++++++++
 t/t3400-rebase.sh            |   26 ++++++++++++++++++++++++++
 3 files changed, 45 insertions(+), 1 deletions(-)