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.
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.
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":
A---B---C topic
/
D---E---F---G master
From this point, the result of either of the following commands:
git rebase master
git rebase master topic
would be:
A'--B'--C' topic
/
D---E---F---G master
A range of commits does not make sense as the first argument, since everything is based on one commit.
How would this be different from
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.Furthermore, running
git rebase foo bar --onto bazwill also “abandon” any descendant commits/branches ofbar, 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 bazwill rebase any descendants ofbaronto the parent offoo, to ensure that no commits are based off of the old versions of the rebased commits.I think you mean
git rebase fooIt’s different when
bar!=headThe 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-branchlessalso 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 thegit movecommand’s set of flags almost as much asgit 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:
A range of commits does not make sense as the first argument, since everything is based on one commit.