[RFC] rebase: be cleverer with rebased upstream branches

[RFC] rebase: be cleverer with rebased upstream branches

[Martin von Zweigbergk]

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 @{upstream}', the reflog would not be
walked. This patch teaches "git rebase" the same reflog-walking tricks
that 'git pull --rebase' already knows.

Apart from making 'git rebase' better aligned with 'git pull --rebase',
this may also be useful on its own 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 does
one step of 'reflog' walking even when the reflog is not used. 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 (let's say
'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
in place of '$ref@{1}'.
---
Junio, don't apply this patch yet, as I will rebase it on top of the
refactored rebase code once I'm done with that (to make it work with
interactive rebase as well).

However, it should apply cleanly on top of the patches in
http://thread.gmane.org/gmane.comp.version-control.git/160682/, and maybe
even right on top of master.

The documentation was copied from git-pull before the patch on on that
documentation that I sent out a little while ago, so the documentation
for this patch will at the very least be updated accordingly.

Should the "RECOVERING FROM UPSTREAM REBASE" section of
Documentation/git-rebase.txt be updated?


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

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 30e5c0e..1baddd2 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -24,7 +24,12 @@ it remains on the current branch.
 All changes made by commits in the current branch but that are not
 in <upstream> are saved to a temporary area.  This is the same set
 of commits that would be shown by `git log <upstream>..HEAD` (or
-`git log HEAD`, if --root is specified).
+`git log HEAD`, if --root is specified). If, however, there is a ref
+for the upstream branch, and this branch was rebased since the
+current branch was last rebased, the rebase uses that information to
+avoid rebasing changes done on the upstream branch. If you do not want
+'git rebase' to use this intelligence, refer to the upstream without
+using a reference (e.g. 'master~0').
 
 The current branch is reset to <upstream>, or <newbase> if the
 --onto option was supplied.  This has the exact same effect as
diff --git a/git-rebase.sh b/git-rebase.sh
index 847555c..fade99a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -495,6 +495,19 @@ case "$#" in
 esac
 orig_head=$branch
 
+test -n $upstream_name && for reflog in \
+	$(git rev-list -g $upstream_name 2>/dev/null)
+do
+	if test $reflog = $(git merge-base $reflog $branch)
+	then
+		if test $reflog != $(git merge-base $onto $reflog)
+		then
+			upstream=$reflog
+		fi
+		break
+	fi
+done
+
 # Now we are rebasing commits $upstream..$branch (or with --root,
 # everything leading up to $branch) on top of $onto
 
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 349eebd..b64df31 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -209,4 +209,30 @@ test_expect_success 'rebase -m can copy notes' '
 	test "a note" = "$(git notes show HEAD)"
 '
 
+test_expect_success 'rebase against rebased upstream uses reflog' '
+	git checkout my-topic-branch &&
+	echo "Conflicting modification" > B &&
+	git add B &&
+	git commit -m "Modify B" &&
+	git reset --hard nonlinear &&
+	git checkout -b old-topic my-topic-branch@{1} &&
+	echo def > D &&
+	git add D &&
+	git commit -m "Add D" &&
+	git rebase my-topic-branch &&
+	test $(git rev-parse HEAD^) = $(git rev-parse my-topic-branch)
+'
+
+test_expect_success 'rebase against forwarded upstream does not reapply patches' '
+	git checkout my-topic-branch &&
+	echo abc > B &&
+	git add B &&
+	git commit -m "Conficting B" &&
+	git reset HEAD~2 &&
+	git reset HEAD@{1} &&
+	git checkout old-topic &&
+	git rebase my-topic-branch &&
+	test $(git rev-parse HEAD^) = $(git rev-parse my-topic-branch)
+'
+
 test_done
-- 
1.7.3.2.167.ga361b

Re: [RFC] rebase: be cleverer with rebased upstream branches

[Santi Béjar]

On Fri, Nov 12, 2010 at 9:11 PM, Martin von Zweigbergk
<martin.von.zweigbergk@gmail.com> wrote:
> 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 @{upstream}', the reflog would not be
> walked. This patch teaches "git rebase" the same reflog-walking tricks
> that 'git pull --rebase' already knows.
>
> Apart from making 'git rebase' better aligned with 'git pull --rebase',
> this may also be useful on its own 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 does
> one step of 'reflog' walking even when the reflog is not used. 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 (let's say
> '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
> in place of '$ref@{1}'.

In the code I don't see when b) is different to call it without
command line branches. And if it is different I suppose it is a bug.

The code must stay in git-pull.sh because there it has more
information (commit before and after fetch) than in git-rebase,
essentially when reflogs are disabled.

> ---
> Junio, don't apply this patch yet, as I will rebase it on top of the
> refactored rebase code once I'm done with that (to make it work with
> interactive rebase as well).

>From a cursory view it looks ok.

Santi

Re: [RFC] rebase: be cleverer with rebased upstream branches

[Martin von Zweigbergk]

On Sat, Nov 13, 2010 at 6:30 PM, Santi Béjar <santi@agolina.net> wrote:
> On Fri, Nov 12, 2010 at 9:11 PM, Martin von Zweigbergk
> <martin.von.zweigbergk@gmail.com> wrote:
>> 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 @{upstream}', the reflog would not be
>> walked. This patch teaches "git rebase" the same reflog-walking tricks
>> that 'git pull --rebase' already knows.
>>
>> Apart from making 'git rebase' better aligned with 'git pull --rebase',
>> this may also be useful on its own 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 does
>> one step of 'reflog' walking even when the reflog is not used. 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 (let's say
>> '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
>> in place of '$ref@{1}'.
>
> In the code I don't see when b) is different to call it without
> command line branches. And if it is different I suppose it is a bug.

The difference is somewhere in the code for 'git fetch'. I'm trying to
refer to the same thing as I did in
http://thread.gmane.org/gmane.comp.version-control.git/160004/focus=160939.

> The code must stay in git-pull.sh because there it has more
> information (commit before and after fetch) than in git-rebase,
> essentially when reflogs are disabled.

Yes, I think that's what I meant by reason 'a)', but maybe I could have
explained it in a better way.