Re: tracking branch for a rebase

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Sep 4, 2009, 18:59 UTC
Message-ID: <20090904185949.GA21583@atjola.homenet>
In-Reply-To: <20090904181846.GC19093@coredump.intra.peff.net>

On 2009.09.04 14:18:46 -0400, Jeff King wrote:

Show 9 quoted lines

> On Fri, Sep 04, 2009 at 04:31:57PM +0200, Michael J Gruber wrote:
> 
> > Making [rebase against upstream] the default for rebase without
> > arguments may meet some objections (oh no, I didn't mean to rebase),
> > but I guess it's worth trying.
> 
> FWIW, that has been a patch I have been meaning to do for a while. I
> don't see it as any more error-prone than "git pull" without arguments.
> In either case, you can always recover with a reset from the reflog.

Note that with:
	branch.foo.remote = origin
	branch.foo.merge = refs/heads/foo

"git pull --rebase" is not the same as: "git fetch origin && git rebase origin/foo", but:

git fetch origin && git rebase --onto origin/foo $reflog_merge_base

Where $reflog_merge_base is the first merge base is found between the current branch head, and the reflog entries for origin/foo.

Same deal for "git pull --rebase origin bla", which is not: "git fetch origin bla && git rebase FETCH_HEAD", but:

git fetch origin && git rebase --onto FETCH_HEAD $reflog_merge_base

Where again $reflog_merge_base is found by looking at the reflog for origin/foo.

It does that to try to automatically handle cases where upstream has been rebased. I'm not completely sure whether I like or hate that. Especially the "git pull --rebase <remote> <refspec>" case seems very weird to me. And if "rebase" is to pickup the same default as "pull", I guess it should also show the same behaviour, but just skips the "fetch" part?

> The biggest question is whether it should respect branch.*.merge, or
> just branch.*.rebase (I never use the latter simply because I never use
> "git pull", but I think it is probably reasonable to restrict it to
> cases where you said you are interested in rebasing in general).

Hm, you'll probably want "git merge" to pickup the default as well then, right? And that should only do so if branch.*.rebase is not set. So effectively, you still have to use the right command, but can skip the argument. Having to deal a lot with git-svn, I also regulary use its "git svn rebase --local", which means "just rebase, don't fetch".

Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe its idea could be taken, so we get "git pull --local" to just skip the fetch part, but keep "git rebase" and "git merge" 'dumb', requiring explicit arguments.

(In the past, I once argued for deprecating "pull", and having merge/rebase doing the fetch as well, with a --local argument that stops them from doing so. That was probably mostly due to the fact that I ran into too many people that simply didn't understood that "git pull" is not "svn up". I still kind of like the idea, but seeing just how often I use rebase/merge with already fetched stuff, I can see how having to use a --local flag with them all the time would be quite a PITA, but now, having the --local flag for "pull" seems to make sense to me.)

Björn