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

[Jeff King <peff@peff.net>]

On Sun, May 27, 2018 at 12:15:40AM +0530, Kaartic Sivaraam wrote:

> > Hmm, actually, I suppose the true value of the warning is to help people
> > doing "git branch -l foo", and it would still work there. The "more
> > extreme" from your suggested patch would only affect "branch -l".
> > 
> > Still, I think I prefer the gentler version that we get by keeping it as
> > a warning even in the latter case.
> >
> 
> I never wanted to suppress the warning message in the latter case. I
> just wanted to avoid listing the branches. Actually the patch I sent in
> one the previous threads[1] that avoids listing the branches has the
> following behaviour,
> 
> $ git branch -l
> warning: the '-l' alias for '--create-reflog' is deprecated;
> warning: it will be removed in a future version of Git
> usage: git branch [<options>] [-r | -a] [--merged | --no-merged]
>    or: git branch [<options>] [-l] [-f] <branch-name> [<start-point>]
>    or: git branch [<options>] [-r] (-d | -D) <branch-name>...
>    or: git branch [<options>] (-m | -M) [<old-branch>] <new-branch>
>    or: git branch [<options>] (-c | -C) [<old-branch>] <new-branch>
>    or: git branch [<options>] [-r | -a] [--points-at]
>    or: git branch [<options>] [-r | -a] [--format]
> 
> 
> So, the warning message isn't lost. It just prevents the listing of
> branches.

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

> Wait, maybe I'm misunderstanding what you mean by "warning". You're
> probably meaning something related to the way Git exits in both cases.
> With your patch "git branch -l" prints a warning, lists the branches and
> has an exit status of 0. With my patch it prints the warning, the usage
> specifications with exit status 128. In that case, I still don't think
> it's bad to turn "git branch -l" into an error now as it's been
> incorrect for a long time now and it's not wrong if we correct it now.
> 
> 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).

-Peff