Jeff King <peff@xxxxxxxx> writes:
> 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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html