Jeff King wrote: > On Sat, Jun 05, 2021 at 10:18:14PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > As for the proposal, I don't use "branch -v" all that much much, so I > > don't have strong knee-jerk feelings on it, but just considering it now > > I'd think that the current default is a fundamentally better > > approximation of what most users would like as a default. > > > > I.e. I think it's fair to say that to the extent that most users have > > topic branches they're part of some pull-request workflow where they're > > always tracking the one upstream they always care about, usually > > origin/master. > > I'm in the same boat. I don't use "branch -v" either, but showing the > upstream name wouldn't be at all helpful to me, since it they would all > just be "origin/master". But this patch is not for you, it's for the majority of git users. > (This will vary based on workflow, but the > other common workflow would probably just show "topic" being based on > "origin/topic"). Based on what evidence? As I showed in [1], all the top results when googling "upstream branch" show the upstream branch being used in the opposite way: it's set to the place you push to: git push --set-upstream @ github/my-pull-request > > The -v output showing the ahead/behind relationship to that branch > > without naming it is thus the best use of the limited space we have, and > > with a bit more verbosity under -vv we'd show the (usually the same for > > all of those) upstream name. > > The notion of what to show for a verbose format may depend on workflow, > or even what the user's currently interested in. These days we have > --format to give much more flexible output. > > The "-v" and "-vv" options predate --format, but these days are > implemented on top of it (they literally build a format string that's > passed into ref-filter.c's interpreter). > > So we could document them as: behave as if "--format=..." was given on > the command line (unfortunately "..." here is a complex set of %(if) > mechanisms, but it would mostly be for reference; nobody would need to > type it). You mean like this? %(if:notequals=refs/remotes)%(refname:rstrip=-2)%(then)%(if)%(HEAD)%(then)* [32m%(else)%(if)%(worktreepath)%(then)+ [36m%(else) %(end)%(end)%(align:34,left)%(refname:lstrip=2)%(end)[m %(objectname:short) %(if)%(upstream:track)%(then)%(upstream:track) %(end)%(contents:subject)%(else) [31m%(align:34,left)remotes/%(refname:lstrip=2)%(end)[m%(if)%(symref)%(then) -> %(symref:short)%(else) %(objectname:short) %(contents:subject)%(end)%(end) I don't think that's particularly useful to anyone. > And then it is not a far leap to change that to: behave as if --format > was set to the value of branch.verboseFormat, and the default of that > config option is "...". And then anybody can make "branch -v" behave > however they like. I don't think telling users to do `git command --code="type here the code you want git to do"` is very user friendly. I don't even want to look at that huge-almost-unparsable string any more than I have to, and you are suggesting that *all* our users subject themselves to that pain in order to fine-tune the output of `git branch -v`? And what about `git branch -vv`? Are we going to ask users to fill an even bigger branch.verboseverboseFormat configuration that it's mostly repeating what branch.verboseFormat has? I'm not interested in implementing that in the least. But even if that was implemented, the whole point of this patch is about what the default value of branch.verboseFormat should be. Do I need to produce a list of the top 10 Google results of "git branch -v" vs. "git branch -vv", to show that most people don't find the output of -v useful? Or what kind of evidence would satisfy you? Cheers. [1] https://lore.kernel.org/git/60be3b2d6e1e6_39c0a20883@natae.notmuch/ -- Felipe Contreras
