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

From: Stefano Lattarini <[email-masked]>
Date: Wed, 14 Aug 2013 18:36:23 +0100

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