On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> Felipe Contreras <felipe.contre...@gmail.com> 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


Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to