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!
* masterI 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
Quoted 3 lines · Stefano Lattarini
... 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 ;-)
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.
Quoted 5 lines · Stefano Lattarini
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 "@").
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]
Quoted 8 lines · Junio C Hamano
Quoted 5 lines · Stefano Lattarini
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.
Quoted 6 lines
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").
Quoted 8 lines
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:
Quoted 14 lines
Quoted 5 lines · Stefano Lattarini
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 "@").
Quoted 7 lines
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?
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
Quoted 21 lines · Johannes Sixt
Am 14.08.2013 20:05, schrieb Junio C Hamano:
Quoted 20 lines
Quoted 5 lines · Stefano Lattarini
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 "@").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.
Quoted 7 lines
Quoted 1 line
What do others think?
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.
Quoted 7 lines · Junio C Hamano
Johannes Sixt <[email protected]> writes:
[SNIP]
Quoted 3 lines
Stefano's use-case, where @/foo is turned into HEAD/foo, indicates a bug.
Quoted 9 lines
Quoted 3 lines
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