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
$ git branch # New git.
@/foo # <-- good
HEAD/bar # <-- BAD!
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
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