Re: [RFC/largely untested/PATCH] sha1_name: interpret ~n as HEAD~n
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Introducing a shortcut ~n for HEAD~n does not introduce new
> inconsistencies (it's a shortcut for a commit, for every command which
> takes a commit) - and does not contradict introducing -n at all, btw.
I thought we already ruled out ~n because many shells think ~n is a path.
> But introducing -n means introducing a range like revision argument to a
> command which does not grok ranges at all, so that is a much deeper
> decision.
I do not think so.
When I originally wrote format-patch and rebase, Linus was finishing up making the "range notation" easier to use around rev-list (and later log). It was not apparent to me that what these two commands operated were a range, by deviating from the "log" syntax two commands could take their operand in a more workflow-specific way (which in turn led to a shorter keystrokes, as you only wrote only one endpoint because the other end was implicit).
The original syntax of format-patch (which by the way is still supported) is to give what we call the upstream these days, like this:
git format-patch origin
which then is internally turned into a moral equivalent of
git rev-list --no-merges origin..HEAD
to find out which commit to output (and run "git diff-tree -p --stdin" on). The command originally only accepted this short-hand form without giving the users ways to affect underlying "range" any other way. But later we found that it is better allow users to use the "log" syntax, for reasons including:
- HEAD may not always be the topic you want to submit; and
- you may not want to submit all commits since the fork point
(i.e. endpoint might want to be HEAD~4 or mytopic~3).
The history behind "rebase" is pretty similar. Again, with the original syntax you give the "upstream":
git rebase origin
git rebase origin mytopic
and again these were internally turned into a moral equivalent of
... optionally "git checkout mytopic" if given
git rev-list --no-merges origin..HEAD
to find out which commit to replay on top of the updated base (this is a natural consequence that the original "rebase" was "format-patch" piped into "am").
"git rebase origin.." and "git rebase origin..mytopic" would be a way to express this operation more naturally. The former would rebase the current branch, and the latter would checkout mytopic branch and rebase it.
One extra reason (which does not apply to format-patch) that rebase wasn't done that way was purely technical. Back then, unless you are prepared to parse these range arguments yourself, once you feed them to rev-parse machinery, you wouldn't be able to tell if the user said "origin..mytopic" or "origin..mytopic^0". The former should rebuild mytopic branch while the latter should leave mytopic branch intact and instead give you a rebuilt history for mytopic branch on a detached HEAD.
I think these days the internal rev-parse machinery passes enough information down add_pending_object() codepath (and in a scripted Porcelain, you can say "rev-parse --symbolic origin..HEAD" to pry it apart), so it should be possible to express what range "rebase" wants to operate on in its natural notation that is used by the log family of commands, if we wanted to.
Michael J Gruber
