Re: [PATCH v3] Add new @ shortcut for HEAD
From: Felipe Contreras <hidden>
Date: 2016-06-15 22:57:06
On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:quoted
On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano [off-list ref] wrote:quoted
Felipe Contreras [off-list ref] writes:quoted
So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we can't remove '{0}'? This patch allows '@' to be the same as 'HEAD'.While the above reasoning is cute, it is misleading. If you start from HEAD@{1}~0^0, we can remove '^0', we can remove '~0', but you cannot remove HEAD from the remaining "HEAD@{1}" without changing what it means. @{1} is where the current branch was, while HEAD@{1} is where you were---they are different when you have just did "git checkout anotherbranch". HEAD@{1} is the tip of your previous branch, @{1} is where anotherbranch was before its tip became the commit you have checked out.Replace @{1} with @{u} and it holds.Yes and no. Starting from HEAD@{u}~0^0, we can remove ^0 and ~0, and you remove HEAD from the remaining "HEAD@{u}" to get @{u} and all of them still mean the same thing. It is the other branch your current branch is integrating with. But that decomposition does not get you to HEAD which is the final destination you want to reach. As soon as you drop the remaining {u}, it suddenly changes the meaning and start referring to the current branch.
Yeah, @something has different meaning depending on what that
'something' is. We could add @{this-branch} to mean this is basically
a no-op, and then we can do the HEAD@{this-branch}~0^0 reduction
straight-forwardly, but I think it's overkill to add a new idiom only
to prove a point.
At the end of the day the important thing is that @ is the same as
@something, except without the 'something' in there. That's why the
shortcut is @, and not '.', or '+', or '&', or any number of other
single characters we could have chosen.
quoted
quoted
So I'd suggest toning it down, perhaps something like this: Even though we often can do without having to type "HEAD", e.g. "git log origin.." substitutes missing RHS with "HEAD", sometimes we still do need to type "HEAD" (thats six f*cking keystrokes "Caps Lock", "H", "E", "A", "D" and finally "Caps Lock").I don't know what RHS means, and I don't use caps lock :)"right hand side"? You can say "Hold down Shift", H, E, A, D and "Release Shift" ;-).
Yeah, but the point is that different people have different ways of doing it. Even if it was 'head' it would be a burden.
quoted
quoted
That is four keystrokes too many to name an often needed reference. Make "@" usable as its synonym.Yeah, that's nice, but doesn't explain why "@", and why not something else.The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid explanation why it is "@", either.
Let's pick '+' then. Or something else.
But that does _not_ mean "@" is a good choice. Nor the explanation has to be based on the "starting from this and strip" progression. "@" is already special and is familiar to users when specifying a ref, and that is a good enough reason (you can of course say that in the log message).
Exactly, because ref@something is used for operations on a ref. If 'ref' is missing, it only makes sense to use HEAD (or something like that), and if 'something' is missing, it only makes sense to make it a no-op, but since we don't want to forbid refs with names like 'master@'. That's the reason why '@' makes sense, and not any other character. Cheers. -- Felipe Contreras