Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

From: Jacob Keller <jacob.keller@gmail.com>
Date: Mar 25, 2018, 07:15 UTC
Message-ID: <CA+P7+xr2-OidiX9ve6GwOR4pSOe4Gn=A3Aow5L=oLZgZE+XqMQ@mail.gmail.com>
In-Reply-To: <20180325043337.GA32465@sigill.intra.peff.net>

On Sat, Mar 24, 2018 at 9:33 PM, Jeff King <peff@peff.net> wrote:

Show 7 quoted lines

> IMHO we should do one of:
>
>   1. Nothing. ;)
>
>   2. Complain about "-l" in list mode to help educate users about the
>      current craziness.
>

I think we should do this at a minimum. It's easy, and it doesn't break any scripts who are doing something sane.

>   3. Drop "-l" (probably with a deprecation period); it seems unlikely
>      to me that anybody uses it for branch creation, and this would at
>      least reduce the confusion (then it would just be "so why don't we
>      have -l" instead of "why is -l not what I expect").

Personally, I'd prefer this, because it's minimal effort on scripts part to fix themselves to use the long option name for reflog, and doesn't cause that much heart burn.

Show 7 quoted lines

>
>   4. Repurpose "-l" as a shortcut for --list (also after a deprecation
>      period). This is slightly more dangerous in that it may confuse
>      people using multiple versions of Git that cross the deprecation
>      line. But that's kind of what the deprecation period is for...
>
> -Peff

I don't think this is particularly all that valuable, since we default to list mode so it only helps if you want to pass an argument to the list mode (since otherwise we'd create a branch). Maybe it could be useful, but if we did it, I'd do it as a sort of double deprecation period where we use one period to remove the -l functionality entirely, before adding anything back. I think the *gain* of having -l is not really worth it though.

Regards, Jake