git rebase foo..bar
git rebase foo..bar
How would this be different from git rebase bar?
git rebase bar
The closest equivalent would be git rebase foo bar. I think it’s poor UI that you can’t uniformly use the commit-range notation in places where you want to specify a range of commits.
git rebase foo bar
Furthermore, running git rebase foo bar --onto baz will also “abandon” any descendant commits/branches of bar, which is to say, keep them on old, outdated versions of the same commits. In practice, this has caused occasionally caused me confusion, since some branches will still be based on outdated code. In comparison, git move --exact foo:bar --dest baz will rebase any descendants of bar onto the parent of foo, to ensure that no commits are based off of the old versions of the rebased commits.
git rebase foo bar --onto baz
git move --exact foo:bar --dest baz
I think you mean git rebase foo
git rebase foo
It’s different when bar != head
The syntax is also different (obviously). I think that’s the point in that sentence, that different syntax is used in different places to mean the same thing.
git-branchless also adds way more powerful rebase functionality (https://blog.waleedkhan.name/bringing-revsets-to-git/#better-rebasing). That’s related to the revset syntax, because having a consistent syntax for specifying revisions makes it easier to implement those features. Otherwise you’d have to bloat the git move command’s set of flags almost as much as git log’s.
I do not. The first argument to rebase specifies the tip of the thing you are rebasing onto (or rather, the commit used to determine the most recent common parent). So that is the last commit in a range, not the first. The man page makes it pretty clear:
Assume the following history exists and the current branch is "topic":
From this point, the result of either of the following commands:
git rebase master
git rebase master topic
A range of commits does not make sense as the first argument, since everything is based on one commit.