New special handing of '@' character broke my use case

Hello list.

In the last year or so, I developed a personal idiom of using a naming scheme of "@/BRANCH-NAME/<NUM>"to "save" the older versions of branches I'm going to rebase (interactively or not). Here is an idealized example of my use case:

   $ git co --help
   `git co' is aliased to `checkout'
   $ git co -b topic
   $ ... hack hack hack ...
   $ git co master && git pull # Let's say this brings in 100 commits
   $ git co topic # I want to rebase this to avoid merge conflicts later
   $ git branch @/topic/1 # So I save "original version" of the branch
   $ git rebase master # Do the rebase, solve conflicts etc.
   $ ... hack hack hack (20 commits) ...
   # Here I notice botched commits messages and badly-ordered
   # commits in the last 10 commits or so.  I want to fix that.
   $ git branch @/topic/2 # Save "latest version" of the branch
   $ git rebase -i HEAD~12 # Fix issues

My problems is that some new automagical interpretation of the bare '@' character (introduced after 1.8.3) has destroyed my use case:

   $ /usr/bin/git --version
   git version 1.8.3
   $ git --version
   git version 1.8.4.rc2
   $ git co master
   $ /usr/bin/git branch @/foo    # Old git
   $ git branch
     @/foo   # <-- good
   * master
   $ git branch                   # New git.
     @/foo    # <-- good
     HEAD/bar # <-- BAD!
   * master

I don't want to ask you to revert this new behaviour, but I'd like to at least have an option to disable it. Even better if such an option is already present -- in which case, could you just point me at it?

Failing that, I can re-train myself to use another character (like '=' or '+') to take the same role '@' has hold for me until today, no big deal. But in that case, I'd like some assurance that such a character is not going to be turned into a magical character some time in the future ;-)

Thanks,
   Stefano

Stefano Lattarini <stefano.lattarini@gmail.com> writes:

I do not think it is simply not worth the complexity to selectively disable it. If it is a regression, it is much better to simply revert, if we can (it appears that cdfd9483 (Add new @ shortcut for HEAD, 2013-05-07) can be reverted without any textual context, but there may already be new stuff that depends on the "@").

For the upcoming release, I am very much tempted to revert it and let the topic retried, by people who really want the "let's save four keystrokes and replace it with @ aka Shift-<something>", without hurting your use case (and others), after the upcoming release.

What do others think?

[re-sending to the list, sorry Junio for the duplicate mail]

On 08/14/2013 07:05 PM, Junio C Hamano wrote:
 > Stefano Lattarini <stefano.lattarini@gmail.com> writes:
 >
 >> My problems is that some new automagical interpretation of the bare
 >> @' character (introduced after 1.8.3) has destroyed my use case:
 >> ...
 >> I don't want to ask you to revert this new behaviour, but I'd like to
 >> at least have an option to disable it.
 >
 > I do not think it is simply not worth the complexity to selectively
 > disable it.  If it is a regression, it is much better to simply
 > revert, if we can (it appears that cdfd9483 (Add new @ shortcut for
 > HEAD, 2013-05-07) can be reverted without any textual context, but
 > there may already be new stuff that depends on the "@").
 >
I'm not sure I want to force a revert simply to cater to a personal 
idiom of mine (and not that important).  I'd first like to hear what the 
community thinks about the issue (with silence meaning "don't revert").

 > For the upcoming release, I am very much tempted to revert it and
 > let the topic retried, by people who really want the "let's save
 > four keystrokes and replace it with @ aka Shift-<something>",
 > without hurting your use case (and others), after the upcoming
 > release.
 >
 > What do others think?
 >
I second this question :-)

Thanks,
   Stefano

Am 14.08.2013 20:05, schrieb Junio C Hamano:

Stefano's use-case, where @/foo is turned into HEAD/foo, indicates a bug.

In my opinion, the topic, which touches a central part of ref handling, was a bit hurried (and this report is a symptom of it), and I wouldn't mind seeing it reverted.

-- Hannes

Johannes Sixt <j6t@kdbg.org> writes:

Thanks; you said it much better than I did. I think the short-hand is not a bad idea by itself, but the execution may need to be redone a bit more carefully, and it is prudent to revert it from the upcoming release.

On 08/14/2013 09:57 PM, Junio C Hamano wrote:
 > Johannes Sixt <j6t@kdbg.org> writes:
 >
 > [SNIP]
 >
 >> Stefano's use-case, where @/foo is turned into HEAD/foo,
 >> indicates a bug.
 >>
 >> In my opinion, the topic, which touches a central part of ref
 >> handling, was a bit hurried (and this report is a symptom of it), and
 >> I wouldn't mind seeing it reverted.
 >
 > Thanks; you said it much better than I did.  I think the short-hand
 > is not a bad idea by itself, but the execution may need to be redone
 > a bit more carefully, and it is prudent to revert it from the
 > upcoming release.
 >
Thanks both for taking care of this issue with the usual speed and
clarity.

Best regards,
   Stefano

Stefano Lattarini <stefano.lattarini@gmail.com> writes:

I'd say that any special letter could be considered a fair game by the next person who would want a funky short-cut. If you used "S" or something, e.g. "git branch S/ropic/1" etc., it would be very unlikely to conflict with any such future changes.