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

[Jeff King <peff@peff.net>]

On Sun, Mar 25, 2018 at 12:28:30AM -0400, Eric Sunshine wrote:

> On Sun, Mar 25, 2018 at 12:10 AM, Jeff King <peff@peff.net> wrote:
> > Alternatively, we could at least detect the situation that confused you:
> >
> > diff --git a/builtin/branch.c b/builtin/branch.c
> > @@ -676,6 +676,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> > +       if (list && reflog)
> > +               die(_("--reflog in list mode does not make sense"));
> > +
> >
> > That doesn't help somebody mistakenly doing "git branch -l foo", but
> > more likely they'd do "git branch -l jk/*" if they were trying to list
> > branches (and then "branch" would barf with "that's not a valid branch
> > name", though that may still leave them quite confused).
> 
> Assuming that existing clients of "-l" (if there are any) only invoke
> "git branch -l <name>" to create a new branch, then it would be
> possible to interpret "-l" as --list when <name> is an existing
> branch. That is, the "-l" in "git branch -l" and "git branch -l
> <existing-branch>..." is recognized as --list, and (for backward
> compatibility only) the "-l" in "git branch -l <new-branch>" is still
> recognized as --create-reflog.
> 
> This idea falls flat, however, if there are clients out there which
> actually depend upon "git branch -l <existing-branch>" failing.

I agree that might work most of the time as a sort of "do what I mean",
but I'd prefer to avoid those kinds of magic rules if we can. They're
very hard to explain to the user, and can be quite baffling when they go
wrong.

IMHO we should do one of:

  1. Nothing. ;)

  2. Complain about "-l" in list mode to help educate users about the
     current craziness.

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

  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