Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

[Jeff King <peff@peff.net>]

On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Right, what I meant by "gentler" is that we continue to perform the same
> > behavior as the old version, alongside the warning. It's arguable here
> > because running "git branch -l" has _always_ been wrong. It's just wrong
> > in a way that happens to do what the user wants. ;)
> > ...
> >> Anyways, if you think it mustn't turn into an error now and only in the
> >> next stage, a suggestion follows in another thread.
> >
> > I don't think "mustn't", but I have a slight preference for what I
> > posted, as I think it is a little friendlier during the transition (at
> > the risk of somebody missing the warning, but then step 2 turns it into
> > a hard error anyway, so they'll certainly find out then).
> 
> Well, we could keep treating '-l' given in contexts where we have
> silently ignored the option and did "list" instead as before during
> the transition, until the very end where it becomes an explicit
> "list" command, no?  Then there is no need to even warn against '-l'
> that is ignored because we are listing in the earliest step.  The
> only usage that requires a warning then becomes '-l' used for its
> original meaning to create a reflog, right?  That sounds gentler to
> me.

So I think you're proposing:

  - step 0: warn about "-l" when it actually gets used, and otherwise
    continue ignoring

  - step 1: turn "-l" into "--list"

  - step 2: there is no step 2

I can't think of any reason that would work, and it lets us reclaim it
for "--list" sooner. I guess "when it gets used" is maybe not the right
criterion. We'd warn on:

  git branch -l foo

But we wouldn't on:

  git branch -d -l foo

That's clearly nonsense, but we're probably better off complaining. So I
guess the right rule is to warn when we are not in list-mode, and
otherwise quietly accept it.

That does mean that anybody who misses the deprecation warning may be
surprised when "branch -l foo" starts listing instead of creating a
branch with a reflog (whereas in the current 3-step plan, we have a
period in the middle where that's a hard error). That may be OK, though,
and is a natural consequence of getting to the end step sooner (even
with a 3-step plan, anybody who skips the versions in the middle _could_
be surprised).

-Peff