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
