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

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

[Stefano Lattarini]

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

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

[Junio C Hamano]

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 "@").

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: New special handing of '@' character broke my use case

[Junio C Hamano]

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

> ...  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.

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

[Stefano Lattarini]

[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

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

[Johannes Sixt]

Am 14.08.2013 20:05, schrieb Junio C Hamano:
> 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 "@").
>
> 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

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

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Am 14.08.2013 20:05, schrieb Junio C Hamano:
>> 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 "@").
>>
>> 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.

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.

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

[Stefano Lattarini]

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