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 ;-)


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