Re: [PATCH] rebase: use reflog to find common base with upstream

On Wed, Oct 16, 2013 at 12:24:13PM -0700, Jonathan Nieder wrote:

John Keeping wrote:

quoted

                                   Since commit d44e712 (pull: support
rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
chosen the most recent reflog entry which is an ancestor of the current
branch if it can find one.

Change rebase so that it uses the same logic.

Nice idea.

Could pull be made to rely on rebase for this as a follow-up?

It's not an obvious change to do that (at least to me) - pull does the
different steps of figuring out the base and then rebasing at different
points in the script.

[...]

quoted

--- a/git-rebase.sh
+++ b/git-rebase.sh

@@ -437,6 +437,14 @@ then
 			error_on_missing_default_upstream "rebase" "rebase" \
 				"against" "git rebase <branch>"
 		fi
+		for reflog in $(git rev-list -g "$upstream_name" 2>/dev/null)
+		do
+			if test "$reflog" = "$(git merge-base "$reflog" HEAD)"

"git merge-base --is-ancestor" is faster.

We should probably change git-pull to use that as well.

What should happen if HEAD is not a valid commit?  (Tested with:

	$ git checkout --orphan foo
	$ cat >>.git/config <<EOF
	[branch "foo"]
		remote = origin
		merge = refs/heads/master
	EOF
	$ bin-wrappers/git rebase 2>&1 | wc -l
	83

).

Adding "2>/dev/null" to the merge-base line silences most of that, all
we're left with is "fatal: Needed a single revision" which is the same
as I get from master's git-rebase.  I think silencing stderr is the
right thing to do here - in the worst case we just use the merge-base of
the two branches instead of the appropriate reflog entry.