On Mon, Jun 07, 2021 at 10:57:42AM -0500, Felipe Contreras wrote: > 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. In the quoted text above, Ævar mentioned that many users will have a pull-request workflow tracking one upstream. So no, I don't think it's just for me, but anybody with that workflow. But of course i also mentioned other workflows, like... > > (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 That's exactly what I was talking about in the quoted text above. If you use --set-upstream, then your local "topic" will track something like "origin/topic". > > 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. I agree it's hard to follow. It's probably only useful for people who want to modify it to create a custom format (and any documentation could certainly explain it in human-readable terms and then make a mention of the actual code). > > 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'm not quite sure what you think I'm proposing, but it's certainly not that people would type in that code on the command line. It's that "-v" would be documented to behave _as if_ that code had been used with --format. And then extended to use another format of the user's choice from a config variable (which could be based on that format, if they so chose). Of course they can do that already with an alias. The only thing I'm actually suggesting is making "-v" configurable. > But even if that was implemented, the whole point of this patch is about > what the default value of branch.verboseFormat should be. I'm saying that I find your proposed value for that default to be useless, and I suspect many other users will, too. Which is why making it configurable may actually help people. > 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? Don't bother on my account. I have generally found that going more than one round deep of discussion with you does not lead anywhere productive, and I don't intend to continue this thread. -Peff
