On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>>>
>>>> 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.
>>> 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.
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html