On Tue, Apr 30, 2013 at 9:03 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Wed, May 1, 2013 at 4:49 AM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> 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'.
>>
>> So now we can use 'git show @~1', and all that goody goodness.
>>
>> Until now '@' was a valid name, but it conflicts with this idea, so lets
>> make it invalid. Very few people if any probably used this name, if they
>> did, they can rename it by using the full-path (e.g. refs/heads/@).
>
> People can write master short for refs/heads/master, but can't with
> refs/heads/@. Would it be better to detect if dwim_ref("@") exists,
> then disable special '@' and warn user to rename '@' to something
> else? After they have renamed it, make '@' special and forbid it in
> any component in the ref (i.e. refs/heads/@ is forbidden too).
I think that would be extremely tricky. If they have refs/heads/@, we
could try to warn them about the conflict, but I think it would be
pretty clear when 'git foo @' doesn't do what they want, and still
they, can use 'git foo refs/heads/@'.
I think it's overkill to worry prematurely about users that most
likely don't exist. If say, we introduce this for 1.8.4, and some
people suffer from the decision, then we can do something about it for
1.8.4.1, but it's more likely that they would just do 'git branch -m
refs/heads/@ whatever' (we should probably fix that because it doesn't
actually work with any refs/heads/X). Of course, the much much more
likely scenario is that nothing will happen.
If there was an easy fix, we should go for that, but I just don't see any.
--
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