Re: [PATCH] branch: issue "-l" deprecation warning after pager starts
- From
Jeff King <peff@peff.net>
- Date
- May 31, 2018, 05:51 UTC
- Message-ID
- <20180531055100.GC17344@sigill.intra.peff.net>
- In-Reply-To
- <xmqqzi0hety4.fsf@gitster-ct.c.googlers.com>
On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote:
Show 23 quoted lines
> 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