git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 5/6] Add new @ shortcut for HEAD

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 2, 2013, 02:44 UTC
Message-ID
<CAMP44s0yd8EFWCkdFpHzUbdB-www=R6e1Yk-nPwiJDFPaAfYHQ@mail.gmail.com>
In-Reply-To
<CACsJy8D_-S_BvQAa5b2+XpfM2-fJcEQ5EJa4RRtV1vQPEe1emA@mail.gmail.com>
On Tue, Apr 30, 2013 at 9:03 PM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 19 quoted lines
> On Wed, May 1, 2013 at 4:49 AM, Felipe Contreras
> <felipe.contreras@gmail.com> 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
Previous: Duy NguyenNext: Junio C Hamano
Message 19 of 22 in “New @ shortcut for HEAD”
  1. 0/6 New @ shortcut for HEADFelipe Contreras, Apr 30, 2013
  2. 1/6 sha1_name: remove no-opFelipe Contreras, Apr 30, 2013
  3. 2/6 sha1_name: remove unnecessary bracesFelipe Contreras, Apr 30, 2013
  4. 3/6 sha1_name: avoid Yoda conditionsFelipe Contreras, Apr 30, 2013
  5. Junio C HamanoApr 30, 2013
  6. Felipe ContrerasApr 30, 2013
  7. Junio C HamanoApr 30, 2013
  8. Felipe ContrerasApr 30, 2013
  9. Junio C HamanoApr 30, 2013
  10. Junio C HamanoApr 30, 2013
  11. Felipe ContrerasApr 30, 2013
  12. Junio C HamanoApr 30, 2013
  13. Junio C HamanoApr 30, 2013
  14. 4/6 sha1_name: refactor reinterpret()Felipe Contreras, Apr 30, 2013
  15. Junio C HamanoApr 30, 2013
  16. 5/6 Add new @ shortcut for HEADFelipe Contreras, Apr 30, 2013
  17. Junio C HamanoApr 30, 2013
  18. Duy NguyenMay 1, 2013
  19. Felipe ContrerasMay 2, 2013
  20. Junio C HamanoMay 2, 2013
  21. 6/6 sha1_name: allow @@{u} to workFelipe Contreras, Apr 30, 2013
  22. Junio C HamanoApr 30, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.