Re: [BUG] - git rebase -i performs rebase when it shouldn't?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 10, 2010, 04:39 UTC
Message-ID: <7vsk73zzt1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100410042609.GA24295@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

> So no, it's not a bug. Yes, it's a terrible interface. There is really
> no reason IMHO for rebase to take a "which branch to operate on"
> argument at all. It should just operate on HEAD, like merge does. If you
> want to merge on a different branch, you "git checkout" that branch
> first.

I guess it's my turn to say "sorry it was my fault made in pre-maintainer days around 59e6b23 ([PATCH] git-rebase-script: rebase local commits to new upstream head., 2005-06-25).

I used to religiously rebase slushy topics that are not in any stable integration branches (we used to have only 'master' and 'pu'), and

	git rebase master foo
        git rebase master bar
        git rebase master baz

was far easier to type than

	git checkout foo && git rebase master
	git checkout bar && git rebase master
	git checkout baz && git rebase master

when you have many topics. Especially because the exact keystroke sequences are:

	git rebase master foo ENTER
	^P (recall the last line) ^W (delete the last word) bar ENTER
	^P ^W baz ENTER

for the former.  Of course, I can do the same with the latter interface

	sh -c 'git checkout "$1" && git rebase master' - foo ENTER
	^P (recall the last line) ^W (delete the last word) bar ENTER
	^P ^W baz ENTER

so that is not a very good excuse, but at least now people know where it came from ;-)