Re: [PATCH] rebase: use reflog to find common base with upstream
- From
Martin von Zweigbergk <martinvonz@gmail.com>
- Date
- Oct 21, 2013, 05:03 UTC
- Message-ID
- <CANiSa6gqGKAyLwwPVoZ_gzN85_06aTCfkdRRscNNZYs7g1rL0A@mail.gmail.com>
- In-Reply-To
- <d8e9f102609ee4502f579cb4ce872e0a40756204.1381949622.git.john@keeping.me.uk>
On Wed, Oct 16, 2013 at 11:53 AM, John Keeping <john@keeping.me.uk> wrote:
Show 11 quoted lines
> Commit 15a147e (rebase: use @{upstream} if no upstream specified,
> 2011-02-09) says:
>
> Make it default to 'git rebase @{upstream}'. That is also what
> 'git pull [--rebase]' defaults to, so it only makes sense that
> 'git rebase' defaults to the same thing.
>
> but that isn't actually the case. 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.It is exactly this inconsistency between "git rebase" and "git pull --rebase" that confused me enough to make me send my first email to this list almost 4 years ago [1], so thanks for working on this! I finished that thread with:
Would it make sense to teach "git rebase" the same tricks as "git pull --rebase"?
Then it took me a year before I sent a patch not unlike this one [2]. To summarize, the patch did not get accepted then because it makes rebase a little slower (or a lot slower in some cases). "git pull --rebase" is of course at least as slow in the same cases, but because it often involves connecting to a remote host, people would probably blame the connection rather than git itself even in those rare (?) cases.
I think
git merge-base HEAD $(git rev-list -g "$upstream_name")
is roughly correct and hopefully fast enough. That can lead to too long a command line, so I was planning on teaching merge-base a --stdin option, but never got around to it.
Martin
[1] http://thread.gmane.org/gmane.comp.version-control.git/136339 [2] http://thread.gmane.org/gmane.comp.version-control.git/166710