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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 30 May 2018 08:22 AM, Junio C Hamano wrote:
Jeff King <peff@xxxxxxxx> 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.


That sounds interesting. I guess that would avoid the confusion I was speaking of from the beginning of this thread as the warning message would not be shown at all for "git branch -l". Of course, it would then confuse people who discover that "git branch -l" lists and "git branch -l $prefix" creates a branch with name "$prefix" (if it's valid) instead of listing branch names with prefix "$prefix". So, it might be worth considering.

BTW, I suspect this would make the deprecation of "-l" a little unsual as the no. of people who see the deprecation warning would be less as the warning is shown only for "git branch -l $branch" and I also suspect the no. of users of that command would be very less as previously pointed by someone elsewhere.

--
Sivaraam



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux