Felipe Contreras [off-list ref] writes:
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.
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" ;-).
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.
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).
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