{"thread":{"id":"55841","subject":"[PATCH] branch: make -v useful","startedAt":"2021-06-05T01:15:01Z","lastAt":"2021-06-25T16:04:01Z","messageCount":18,"participants":["Felipe Contreras","Ævar Arnfjörð Bjarmason","Jeff King","Kerry, Richard"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"426451","messageId":"20210605011339.2202-1-felipe.contreras@gmail.com","threadId":"55841","inReplyTo":null,"subject":"[PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-05T01:13:39Z","receivedAt":"2021-06-05T01:15:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Currently `git branch -v` shows something like \"[ahead 10]\", but ahead\nof what?\n\nWe git experts know ahead of what, but not what that what is set to. Just\nlike \"[@{upstream}: ahead 10]\" would not be particularly useful to\nanyone that doesn't know, or remembers, what @{upstream} is set to.\n\nOn the other hand \"[master: ahead 10]\" is perfectly clear to anyone.\n\nThis confusion only gets worse when you see \"[ahead 10, behind 100]\". Is\nit master? Is it next? Is it\njohn/experimental-feature-i-based-my-branch-on?\n\nInevitably most users will need to know what @{upstream} is.\n\nSo let's make `git branch -v` output what is most useful:\n\n  [master]\n\nBefore:\n\n  * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful\n\nAfter:\n\n  * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful\n\nAn additional benefit is that `git branch -v` is slightly faster: 30ms\nvs. 60ms on my system.\n\n`git branch -vv` is unaffected.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n\nThis is a reboot of my old patch series [1].\n\nEvery time I use git without this feature I miss it.\n\n[1] https://lore.kernel.org/git/1398027514-19399-1-git-send-email-felipe.contreras@gmail.com/\n\n builtin/branch.c           |  9 ++++-----\n t/t3201-branch-contains.sh |  2 +-\n t/t6040-tracking-info.sh   | 12 ++++++------\n 3 files changed, 11 insertions(+), 12 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex b23b1d1752..7c0d3f7e4e 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -375,16 +375,15 @@ static char *build_format(struct ref_filter *filter, int maxwidth, const char *r\n \t\tstrbuf_addstr(&local, branch_get_color(BRANCH_COLOR_RESET));\n \t\tstrbuf_addf(&local, \" %s \", obname.buf);\n \n+\t\tstrbuf_addf(&local, \"%%(if:notequals=*)%%(HEAD)%%(then)%%(if)%%(worktreepath)%%(then)(%s%%(worktreepath)%s) %%(end)%%(end)\",\n+\t\t\t    branch_get_color(BRANCH_COLOR_WORKTREE), branch_get_color(BRANCH_COLOR_RESET));\n \t\tif (filter->verbose > 1)\n-\t\t{\n-\t\t\tstrbuf_addf(&local, \"%%(if:notequals=*)%%(HEAD)%%(then)%%(if)%%(worktreepath)%%(then)(%s%%(worktreepath)%s) %%(end)%%(end)\",\n-\t\t\t\t    branch_get_color(BRANCH_COLOR_WORKTREE), branch_get_color(BRANCH_COLOR_RESET));\n \t\t\tstrbuf_addf(&local, \"%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s%%(if)%%(upstream:track)\"\n \t\t\t\t    \"%%(then): %%(upstream:track,nobracket)%%(end)] %%(end)%%(contents:subject)\",\n \t\t\t\t    branch_get_color(BRANCH_COLOR_UPSTREAM), branch_get_color(BRANCH_COLOR_RESET));\n-\t\t}\n \t\telse\n-\t\t\tstrbuf_addf(&local, \"%%(if)%%(upstream:track)%%(then)%%(upstream:track) %%(end)%%(contents:subject)\");\n+\t\t\tstrbuf_addf(&local, \"%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s] %%(end)%%(contents:subject)\",\n+\t\t\t\t    branch_get_color(BRANCH_COLOR_UPSTREAM), branch_get_color(BRANCH_COLOR_RESET));\n \n \t\tstrbuf_addf(&remote, \"%%(align:%d,left)%s%%(refname:lstrip=2)%%(end)%s\"\n \t\t\t    \"%%(if)%%(symref)%%(then) -> %%(symref:short)\"\ndiff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh\nindex 349a810cee..53e2d65e67 100755\n--- a/t/t3201-branch-contains.sh\n+++ b/t/t3201-branch-contains.sh\n@@ -261,7 +261,7 @@ test_expect_success 'branch --merged with --verbose' '\n \tgit branch --verbose --merged topic >actual &&\n \tcat >expect <<-EOF &&\n \t  main  $(git rev-parse --short main) second on main\n-\t* topic $(git rev-parse --short topic ) [ahead 1] foo\n+\t* topic $(git rev-parse --short topic ) [main] foo\n \t  zzz   $(git rev-parse --short zzz   ) second on main\n \tEOF\n \ttest_cmp expect actual\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex a313849406..30f80ad61b 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -43,12 +43,12 @@ test_expect_success setup '\n \n t6040_script='s/^..\\(b.\\) *[0-9a-f]* \\(.*\\)$/\\1 \\2/p'\n cat >expect <<\\EOF\n-b1 [ahead 1, behind 1] d\n-b2 [ahead 1, behind 1] d\n-b3 [behind 1] b\n-b4 [ahead 2] f\n-b5 [gone] g\n-b6 c\n+b1 [origin/main] d\n+b2 [origin/main] d\n+b3 [origin/main] b\n+b4 [origin/main] f\n+b5 [brokenbase] g\n+b6 [origin/main] c\n EOF\n \n test_expect_success 'branch -v' '\n-- \n2.32.0.rc2\n\n"},{"id":"426502","messageId":"87czt059sn.fsf@evledraar.gmail.com","threadId":"55841","inReplyTo":"20210605011339.2202-1-felipe.contreras@gmail.com","subject":"Re: [PATCH] branch: make -v useful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-05T20:18:14Z","receivedAt":"2021-06-05T20:36:56Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jun 04 2021, Felipe Contreras wrote:\n\n> Currently `git branch -v` shows something like \"[ahead 10]\", but ahead\n> of what?\n>\n> We git experts know ahead of what, but not what that what is set to. Just\n> like \"[@{upstream}: ahead 10]\" would not be particularly useful to\n> anyone that doesn't know, or remembers, what @{upstream} is set to.\n>\n> On the other hand \"[master: ahead 10]\" is perfectly clear to anyone.\n>\n> This confusion only gets worse when you see \"[ahead 10, behind 100]\". Is\n> it master? Is it next? Is it\n> john/experimental-feature-i-based-my-branch-on?\n>\n> Inevitably most users will need to know what @{upstream} is.\n>\n> So let's make `git branch -v` output what is most useful:\n>\n>   [master]\n>\n> Before:\n>\n>   * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful\n>\n> After:\n>\n>   * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful\n>\n\nHaving applied this patch I find the description a bit confusing. The\nexample led me to believe that you'd stripped the remote name, so the\ncommon case of \"origin/master\" would become \"master\", but instead the\nexample is from a \"fc/branch/sane-colors\" branch where your \"remote\ntracking branch\" is actually tracking your *local* master, i.e. \"remote\n= .\"?\n\nDisambiguating that is one of the reasons we prefix with the remote\nname, but I'd say it makes for a confusing example in a commit message,\nand also if instead of saying:\n\n    branch: make -v useful\n\nIt said e.g.:\n\n    branch: reverse the priority of what -v and -vv show\n\nOr something similar to note that it's not \"useful\" now, but an\nopinionated change about what we should show on verbosity level 1 and 2.\n\nIn any case, this proposed patch is missing a doc update, in\ngit-branch.txt we say both:\n\n    When in list mode, show sha1 and commit subject line for each head,\n    along with relationship to upstream branch (if any). If given twice,\n    print the path of the linked worktree (if any) and the name of the\n    upstream branch, as well (see also git remote show <remote>).\n\nAnd later, for the --track option:\n\n    When creating a new branch, set up branch.<name>.remote and\n    branch.<name>.merge configuration entries to mark the start-point\n    branch as \"upstream\" from the new branch. This configuration will\n    tell git to show the relationship between the two branches in git\n    status and git branch -v.\n\nBoth of those need to be updated, and I think the commit messages should\ndiscuss whether we break this promise of having consistent output\nbetween \"status\" and \"branch -v\" now.\n\nAs for the proposal, I don't use \"branch -v\" all that much much, so I\ndon't have strong knee-jerk feelings on it, but just considering it now\nI'd think that the current default is a fundamentally better\napproximation of what most users would like as a default.\n\nI.e. I think it's fair to say that to the extent that most users have\ntopic branches they're part of some pull-request workflow where they're\nalways tracking the one upstream they always care about, usually\norigin/master.\n\nThe -v output showing the ahead/behind relationship to that branch\nwithout naming it is thus the best use of the limited space we have, and\nwith a bit more verbosity under -vv we'd show the (usually the same for\nall of those) upstream name.\n\nWhereas you are presumably tracking origin/master for some, building on\nyour own topic (or other people's topics) for another etc., I think that\nworkflow is much rarer outside of linux.git and git.git, and even for\nthose most people usually track origin/master with most of their topics.\n\n> An additional benefit is that `git branch -v` is slightly faster: 30ms\n> vs. 60ms on my system.\n\n110ms v.s. 5000ms on my system. Lots of old uncleaned-up topics.\n\nFor what it's worth I remember some past discussion where it was\ndiscussed to have some human-readable cut-off so instead of saying:\n\n    ahead 2, behind 38741\n\nWe'd just fall back on saying \"behind lots\" once your number of behind\nreached some limit (which could dynamically compute as a heuristic based\non repo size, just like the abbrev length)..\n"},{"id":"426510","messageId":"YLv8NWL7WfBRkiGe@coredump.intra.peff.net","threadId":"55841","inReplyTo":"87czt059sn.fsf@evledraar.gmail.com","subject":"Re: [PATCH] branch: make -v useful","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-06-05T22:35:33Z","receivedAt":"2021-06-05T22:35:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 05, 2021 at 10:18:14PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> As for the proposal, I don't use \"branch -v\" all that much much, so I\n> don't have strong knee-jerk feelings on it, but just considering it now\n> I'd think that the current default is a fundamentally better\n> approximation of what most users would like as a default.\n> \n> I.e. I think it's fair to say that to the extent that most users have\n> topic branches they're part of some pull-request workflow where they're\n> always tracking the one upstream they always care about, usually\n> origin/master.\n\nI'm in the same boat. I don't use \"branch -v\" either, but showing the\nupstream name wouldn't be at all helpful to me, since it they would all\njust be \"origin/master\". (This will vary based on workflow, but the\nother common workflow would probably just show \"topic\" being based on\n\"origin/topic\").\n\n> The -v output showing the ahead/behind relationship to that branch\n> without naming it is thus the best use of the limited space we have, and\n> with a bit more verbosity under -vv we'd show the (usually the same for\n> all of those) upstream name.\n\nThe notion of what to show for a verbose format may depend on workflow,\nor even what the user's currently interested in. These days we have\n--format to give much more flexible output.\n\nThe \"-v\" and \"-vv\" options predate --format, but these days are\nimplemented on top of it (they literally build a format string that's\npassed into ref-filter.c's interpreter).\n\nSo we could document them as: behave as if \"--format=...\" was given on\nthe command line (unfortunately \"...\" here is a complex set of %(if)\nmechanisms, but it would mostly be for reference; nobody would need to\ntype it).\n\nAnd then it is not a far leap to change that to: behave as if --format\nwas set to the value of branch.verboseFormat, and the default of that\nconfig option is \"...\". And then anybody can make \"branch -v\" behave\nhowever they like.\n\nIt would break scripts that parse \"branch -v\", of course, but we've been\npretty explicit that this is porcelain (and the plumbing option is\nfor-each-ref).\n\n> For what it's worth I remember some past discussion where it was\n> discussed to have some human-readable cut-off so instead of saying:\n> \n>     ahead 2, behind 38741\n> \n> We'd just fall back on saying \"behind lots\" once your number of behind\n> reached some limit (which could dynamically compute as a heuristic based\n> on repo size, just like the abbrev length)..\n\nThere's some discussion in the sub-thread starting here:\n\n  https://lore.kernel.org/git/7b759564-5544-8845-0594-e8342a0b4ba5@gmail.com/\n\nI do like that direction, but it sounds like there's some complexity\n(maybe less these days if we can rely on having commit-graphs with\ngeneration numbers). There is an AHEAD_BEHIND_QUICK flag, but I think it\ncan only be triggered via \"git status --no-ahead-behind\" (and it's kind\nof unsatisfying, as it only tells you whether the two tips are identical\nor not).\n\n-Peff\n"},{"id":"426616","messageId":"60be3b2d6e1e6_39c0a20883@natae.notmuch","threadId":"55841","inReplyTo":"87czt059sn.fsf@evledraar.gmail.com","subject":"Re: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-07T15:28:45Z","receivedAt":"2021-06-07T15:29:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Fri, Jun 04 2021, Felipe Contreras wrote:\n> \n> > Currently `git branch -v` shows something like \"[ahead 10]\", but ahead\n> > of what?\n> >\n> > We git experts know ahead of what, but not what that what is set to. Just\n> > like \"[@{upstream}: ahead 10]\" would not be particularly useful to\n> > anyone that doesn't know, or remembers, what @{upstream} is set to.\n> >\n> > On the other hand \"[master: ahead 10]\" is perfectly clear to anyone.\n> >\n> > This confusion only gets worse when you see \"[ahead 10, behind 100]\". Is\n> > it master? Is it next? Is it\n> > john/experimental-feature-i-based-my-branch-on?\n> >\n> > Inevitably most users will need to know what @{upstream} is.\n> >\n> > So let's make `git branch -v` output what is most useful:\n> >\n> >   [master]\n> >\n> > Before:\n> >\n> >   * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful\n> >\n> > After:\n> >\n> >   * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful\n> >\n> \n> Having applied this patch I find the description a bit confusing. The\n> example led me to believe that you'd stripped the remote name, so the\n> common case of \"origin/master\" would become \"master\", but instead the\n> example is from a \"fc/branch/sane-colors\" branch where your \"remote\n> tracking branch\" is actually tracking your *local* master, i.e. \"remote\n> = .\"?\n\nYes, in my particular setup I have a local \"master\" and many branches\nbased on it. A simply picked a real example.\n\nBut yeah, it would have been clearer with origin/master.\n\n> Disambiguating that is one of the reasons we prefix with the remote\n> name, but I'd say it makes for a confusing example in a commit message,\n> and also if instead of saying:\n> \n>     branch: make -v useful\n> \n> It said e.g.:\n> \n>     branch: reverse the priority of what -v and -vv show\n\nI guess that depends on what you consider this patch is doing, why, and how.\n\nBut I have no problem with your version.\n\n> Or something similar to note that it's not \"useful\" now, but an\n> opinionated change about what we should show on verbosity level 1 and 2.\n\nI'm not sure I parsed that correctly, but that's the whole point:\nverbosity level 1 is not very useful (I'd argue not useful at all).\n\n> In any case, this proposed patch is missing a doc update, in\n> git-branch.txt we say both:\n> \n>     When in list mode, show sha1 and commit subject line for each head,\n>     along with relationship to upstream branch (if any). If given twice,\n>     print the path of the linked worktree (if any) and the name of the\n>     upstream branch, as well (see also git remote show <remote>).\n> \n> And later, for the --track option:\n> \n>     When creating a new branch, set up branch.<name>.remote and\n>     branch.<name>.merge configuration entries to mark the start-point\n>     branch as \"upstream\" from the new branch. This configuration will\n>     tell git to show the relationship between the two branches in git\n>     status and git branch -v.\n> \n> Both of those need to be updated,\n\nSure, I missed that.\n\n> and I think the commit messages should discuss whether we break this\n> promise of having consistent output between \"status\" and \"branch -v\"\n> now.\n\nBut we don't with \"branch -vv\".\n\n> As for the proposal, I don't use \"branch -v\" all that much much, so I\n> don't have strong knee-jerk feelings on it, but just considering it now\n> I'd think that the current default is a fundamentally better\n> approximation of what most users would like as a default.\n> \n> I.e. I think it's fair to say that to the extent that most users have\n> topic branches they're part of some pull-request workflow where they're\n> always tracking the one upstream they always care about, usually\n> origin/master.\n\nBecause git has poor support for triangular workflows users are forced\nto pick between one of two approaches:\n\n 1. If you rebase a lot you pick origin/master\n 2. If you push a lot you pick github/my-pull-request\n\nThere's a reason `git push --set-upstream` exists.\n\nA quick Google search shows these top results:\n\n1. https://devconnected.com/how-to-set-upstream-branch-on-git/\n\n * git push --set-upstream <remote> <branch>\n * git branch -vv\n\nThe author doesn't even mention any other way to setup branches, and of\ncourse doesn't bother himself with `git branch -v`, which is not useful\nat all for his purposes.\n\n2. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches\n\n  If you want to see what tracking branches you have set up, you can use\n  the -vv option to git branch. This will list out your local branches\n  with more information including what each branch is tracking and if\n  your local branch is ahead, behind or both.\n\nOnce again another author that doesn't bother himself with\n`git branch -v`.\n\nAnd the examples show why:\n\n    iss53     7e424c3 [origin/iss53: ahead 2] Add forgotten brackets\n    master    1ae2a45 [origin/master] Deploy index fix\n  * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it\n    testing   5ea463a Try something new\n\nIn only one example is the upstream branch origin/master.\n\n3. https://stackoverflow.com/questions/1783405/how-do-i-check-out-a-remote-git-branch\n\nThe top answer to \"How do I check out a remote Git branch?\" mentions:\n\n  git checkout -t <name of remote>/test\n\nThis most certainly will not create an origin/master upstream.\n\n4. https://www.git-tower.com/learn/git/faq/track-remote-upstream-branch/\n\n  git checkout --track origin/dev\n  git push -u origin dev\n  git branch -u origin/dev\n\nOnce again no sight of origin/master, which isn't even mentioned in the\nwhole article.\n\n\nSo no, I don't think it's accurate to say that most people would track\norigin/master, in fact, I would say of the people that know how to set\nupstream tracking branches, the minority would pick origin/master.\n\n> The -v output showing the ahead/behind relationship to that branch\n\nWhat branch?\n\nIf I show you the output of my `git branch -v` on git.git do you think you\nwould be able to figure out what branch is being tracked? Not even I\ncould figure that out.\n\n> Whereas you are presumably tracking origin/master for some, building on\n> your own topic (or other people's topics) for another etc., I think that\n> workflow is much rarer outside of linux.git and git.git, and even for\n> those most people usually track origin/master with most of their topics.\n\nThat's an unsupported assumption.\n\nAs I showed above, most pople track the branch they push to, not\norigin/master.\n\nGoogle \"git branch -v\", and you will find mostly official documentation\nand man pages.\n\nGoogle \"git branch -vv\", and you will find mostly blog posts, Stack\nOverflow questions, and cheat sheets.\n\nI think the reason why is obvious.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"426620","messageId":"60be41f6473e2_39c0a208f6@natae.notmuch","threadId":"55841","inReplyTo":"YLv8NWL7WfBRkiGe@coredump.intra.peff.net","subject":"Re: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-07T15:57:42Z","receivedAt":"2021-06-07T15:58:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Sat, Jun 05, 2021 at 10:18:14PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> > As for the proposal, I don't use \"branch -v\" all that much much, so I\n> > don't have strong knee-jerk feelings on it, but just considering it now\n> > I'd think that the current default is a fundamentally better\n> > approximation of what most users would like as a default.\n> > \n> > I.e. I think it's fair to say that to the extent that most users have\n> > topic branches they're part of some pull-request workflow where they're\n> > always tracking the one upstream they always care about, usually\n> > origin/master.\n> \n> I'm in the same boat. I don't use \"branch -v\" either, but showing the\n> upstream name wouldn't be at all helpful to me, since it they would all\n> just be \"origin/master\".\n\nBut this patch is not for you, it's for the majority of git users.\n\n> (This will vary based on workflow, but the\n> other common workflow would probably just show \"topic\" being based on\n> \"origin/topic\").\n\nBased on what evidence?\n\nAs I showed in [1], all the top results when googling \"upstream branch\"\nshow the upstream branch being used in the opposite way: it's set to the\nplace you push to:\n\n  git push --set-upstream @ github/my-pull-request\n\n> > The -v output showing the ahead/behind relationship to that branch\n> > without naming it is thus the best use of the limited space we have, and\n> > with a bit more verbosity under -vv we'd show the (usually the same for\n> > all of those) upstream name.\n> \n> The notion of what to show for a verbose format may depend on workflow,\n> or even what the user's currently interested in. These days we have\n> --format to give much more flexible output.\n> \n> The \"-v\" and \"-vv\" options predate --format, but these days are\n> implemented on top of it (they literally build a format string that's\n> passed into ref-filter.c's interpreter).\n> \n> So we could document them as: behave as if \"--format=...\" was given on\n> the command line (unfortunately \"...\" here is a complex set of %(if)\n> mechanisms, but it would mostly be for reference; nobody would need to\n> type it).\n\nYou mean like this?\n\n  %(if:notequals=refs/remotes)%(refname:rstrip=-2)%(then)%(if)%(HEAD)%(then)* \u001b[32m%(else)%(if)%(worktreepath)%(then)+ \u001b[36m%(else)  %(end)%(end)%(align:34,left)%(refname:lstrip=2)%(end)\u001b[m %(objectname:short) %(if)%(upstream:track)%(then)%(upstream:track) %(end)%(contents:subject)%(else)  \u001b[31m%(align:34,left)remotes/%(refname:lstrip=2)%(end)\u001b[m%(if)%(symref)%(then) -> %(symref:short)%(else) %(objectname:short) %(contents:subject)%(end)%(end)\n\nI don't think that's particularly useful to anyone.\n\n> And then it is not a far leap to change that to: behave as if --format\n> was set to the value of branch.verboseFormat, and the default of that\n> config option is \"...\". And then anybody can make \"branch -v\" behave\n> however they like.\n\nI don't think telling users to do `git command --code=\"type here the\ncode you want git to do\"` is very user friendly.\n\nI don't even want to look at that huge-almost-unparsable string any more\nthan I have to, and you are suggesting that *all* our users subject\nthemselves to that pain in order to fine-tune the output of\n`git branch -v`?\n\nAnd what about `git branch -vv`? Are we going to ask users to fill an\neven bigger branch.verboseverboseFormat configuration that it's mostly\nrepeating what branch.verboseFormat has?\n\nI'm not interested in implementing that in the least.\n\nBut even if that was implemented, the whole point of this patch is about\nwhat the default value of branch.verboseFormat should be.\n\n\nDo I need to produce a list of the top 10 Google results of\n\"git branch -v\" vs. \"git branch -vv\", to show that most people don't\nfind the output of -v useful?\n\nOr what kind of evidence would satisfy you?\n\nCheers.\n\n[1] https://lore.kernel.org/git/60be3b2d6e1e6_39c0a20883@natae.notmuch/\n\n-- \nFelipe Contreras"},{"id":"426626","messageId":"87h7i94ola.fsf@evledraar.gmail.com","threadId":"55841","inReplyTo":"60be3b2d6e1e6_39c0a20883@natae.notmuch","subject":"Re: [PATCH] branch: make -v useful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-07T16:05:35Z","receivedAt":"2021-06-07T16:39:43Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jun 07 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Fri, Jun 04 2021, Felipe Contreras wrote:\n>> \n>> > Currently `git branch -v` shows something like \"[ahead 10]\", but ahead\n>> > of what?\n>> >\n>> > We git experts know ahead of what, but not what that what is set to. Just\n>> > like \"[@{upstream}: ahead 10]\" would not be particularly useful to\n>> > anyone that doesn't know, or remembers, what @{upstream} is set to.\n>> >\n>> > On the other hand \"[master: ahead 10]\" is perfectly clear to anyone.\n>> >\n>> > This confusion only gets worse when you see \"[ahead 10, behind 100]\". Is\n>> > it master? Is it next? Is it\n>> > john/experimental-feature-i-based-my-branch-on?\n>> >\n>> > Inevitably most users will need to know what @{upstream} is.\n>> >\n>> > So let's make `git branch -v` output what is most useful:\n>> >\n>> >   [master]\n>> >\n>> > Before:\n>> >\n>> >   * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful\n>> >\n>> > After:\n>> >\n>> >   * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful\n>> >\n>> \n>> Having applied this patch I find the description a bit confusing. The\n>> example led me to believe that you'd stripped the remote name, so the\n>> common case of \"origin/master\" would become \"master\", but instead the\n>> example is from a \"fc/branch/sane-colors\" branch where your \"remote\n>> tracking branch\" is actually tracking your *local* master, i.e. \"remote\n>> = .\"?\n>\n> Yes, in my particular setup I have a local \"master\" and many branches\n> based on it. A simply picked a real example.\n>\n> But yeah, it would have been clearer with origin/master.\n\n*nod*\n\n>> Disambiguating that is one of the reasons we prefix with the remote\n>> name, but I'd say it makes for a confusing example in a commit message,\n>> and also if instead of saying:\n>> \n>>     branch: make -v useful\n>> \n>> It said e.g.:\n>> \n>>     branch: reverse the priority of what -v and -vv show\n>\n> I guess that depends on what you consider this patch is doing, why, and how.\n>\n> But I have no problem with your version.\n>\n>> Or something similar to note that it's not \"useful\" now, but an\n>> opinionated change about what we should show on verbosity level 1 and 2.\n>\n> I'm not sure I parsed that correctly, but that's the whole point:\n> verbosity level 1 is not very useful (I'd argue not useful at all).\n\nMaybe, anyway I meant to suggest saying something approaching \"reverse\nthe order of the data we consider important\" instead of the equivalent\nof \"make the data useful\".\n\n>> In any case, this proposed patch is missing a doc update, in\n>> git-branch.txt we say both:\n>> \n>>     When in list mode, show sha1 and commit subject line for each head,\n>>     along with relationship to upstream branch (if any). If given twice,\n>>     print the path of the linked worktree (if any) and the name of the\n>>     upstream branch, as well (see also git remote show <remote>).\n>> \n>> And later, for the --track option:\n>> \n>>     When creating a new branch, set up branch.<name>.remote and\n>>     branch.<name>.merge configuration entries to mark the start-point\n>>     branch as \"upstream\" from the new branch. This configuration will\n>>     tell git to show the relationship between the two branches in git\n>>     status and git branch -v.\n>> \n>> Both of those need to be updated,\n>\n> Sure, I missed that.\n>\n>> and I think the commit messages should discuss whether we break this\n>> promise of having consistent output between \"status\" and \"branch -v\"\n>> now.\n>\n> But we don't with \"branch -vv\".\n\nI think the wording there needs to be changed in any case, I'm not sure\nwhat it's supposed to mean.\n\nI think the \"show the relationship between\" there is referring to the\nahead/behind relationship, or maybe it's just speaking more generally\nabout the short (branch -v[-v]) v.s. long (git status) blurb we show\nabout the branch status overall.\n\n>> As for the proposal, I don't use \"branch -v\" all that much much, so I\n>> don't have strong knee-jerk feelings on it, but just considering it now\n>> I'd think that the current default is a fundamentally better\n>> approximation of what most users would like as a default.\n>> \n>> I.e. I think it's fair to say that to the extent that most users have\n>> topic branches they're part of some pull-request workflow where they're\n>> always tracking the one upstream they always care about, usually\n>> origin/master.\n>\n> Because git has poor support for triangular workflows users are forced\n> to pick between one of two approaches:\n>\n>  1. If you rebase a lot you pick origin/master\n>  2. If you push a lot you pick github/my-pull-request\n>\n> There's a reason `git push --set-upstream` exists.\n>\n> A quick Google search shows these top results:\n>\n> 1. https://devconnected.com/how-to-set-upstream-branch-on-git/\n>\n>  * git push --set-upstream <remote> <branch>\n>  * git branch -vv\n>\n> The author doesn't even mention any other way to setup branches, and of\n> course doesn't bother himself with `git branch -v`, which is not useful\n> at all for his purposes.\n>\n> 2. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches\n>\n>   If you want to see what tracking branches you have set up, you can use\n>   the -vv option to git branch. This will list out your local branches\n>   with more information including what each branch is tracking and if\n>   your local branch is ahead, behind or both.\n>\n> Once again another author that doesn't bother himself with\n> `git branch -v`.\n>\n> And the examples show why:\n>\n>     iss53     7e424c3 [origin/iss53: ahead 2] Add forgotten brackets\n>     master    1ae2a45 [origin/master] Deploy index fix\n>   * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it\n>     testing   5ea463a Try something new\n>\n> In only one example is the upstream branch origin/master.\n>\n> 3. https://stackoverflow.com/questions/1783405/how-do-i-check-out-a-remote-git-branch\n>\n> The top answer to \"How do I check out a remote Git branch?\" mentions:\n>\n>   git checkout -t <name of remote>/test\n>\n> This most certainly will not create an origin/master upstream.\n>\n> 4. https://www.git-tower.com/learn/git/faq/track-remote-upstream-branch/\n>\n>   git checkout --track origin/dev\n>   git push -u origin dev\n>   git branch -u origin/dev\n>\n> Once again no sight of origin/master, which isn't even mentioned in the\n> whole article.\n>\n>\n> So no, I don't think it's accurate to say that most people would track\n> origin/master, in fact, I would say of the people that know how to set\n> upstream tracking branches, the minority would pick origin/master.\n>\n>> The -v output showing the ahead/behind relationship to that branch\n>\n> What branch?\n>\n> If I show you the output of my `git branch -v` on git.git do you think you\n> would be able to figure out what branch is being tracked? Not even I\n> could figure that out.\n>\n>> Whereas you are presumably tracking origin/master for some, building on\n>> your own topic (or other people's topics) for another etc., I think that\n>> workflow is much rarer outside of linux.git and git.git, and even for\n>> those most people usually track origin/master with most of their topics.\n>\n> That's an unsupported assumption.\n>\n> As I showed above, most pople track the branch they push to, not\n> origin/master.\n>\n> Google \"git branch -v\", and you will find mostly official documentation\n> and man pages.\n>\n> Google \"git branch -vv\", and you will find mostly blog posts, Stack\n> Overflow questions, and cheat sheets.\n>\n> I think the reason why is obvious.\n\nYes, I stand corrected.\n\nFor what it's worth I think one thing to salvage from my ill-informed\nrambling is that I was under that impression because I set\npush.default=upstream.\n\nBut yes, with \"simple\" being the default and refusing to have\navar/my-topic have an upstream of origin/master my setup is probably not\nthe common case.\n\nI wonder if this should depend on the setting of push.default, or\nwhether we can infer anything at all from that setting. After all you\ncan set it to whatever and then either manually do \"git push <remote>\n<src>:<dst>\" (my usual worklow is just \"git push origin HEAD\"), or\nmanually do the \"git rebase origin/master\" or whatever in the case where\nyour upstream is your own topic branch.\n\n"},{"id":"426643","messageId":"60be5eb6923de_39c0a20817@natae.notmuch","threadId":"55841","inReplyTo":"87h7i94ola.fsf@evledraar.gmail.com","subject":"Re: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-07T18:00:22Z","receivedAt":"2021-06-07T18:01:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Jun 07 2021, Felipe Contreras wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n\n> >> Disambiguating that is one of the reasons we prefix with the remote\n> >> name, but I'd say it makes for a confusing example in a commit message,\n> >> and also if instead of saying:\n> >> \n> >>     branch: make -v useful\n> >> \n> >> It said e.g.:\n> >> \n> >>     branch: reverse the priority of what -v and -vv show\n> >\n> > I guess that depends on what you consider this patch is doing, why, and how.\n> >\n> > But I have no problem with your version.\n> >\n> >> Or something similar to note that it's not \"useful\" now, but an\n> >> opinionated change about what we should show on verbosity level 1 and 2.\n> >\n> > I'm not sure I parsed that correctly, but that's the whole point:\n> > verbosity level 1 is not very useful (I'd argue not useful at all).\n> \n> Maybe, anyway I meant to suggest saying something approaching \"reverse\n> the order of the data we consider important\" instead of the equivalent\n> of \"make the data useful\".\n\nAll right, that transmits the message I want to transmit and is less\nabrasive, so that's good.\n\nI've updated the title, and in fact changed the whole commit message.\n\n> >> Whereas you are presumably tracking origin/master for some, building on\n> >> your own topic (or other people's topics) for another etc., I think that\n> >> workflow is much rarer outside of linux.git and git.git, and even for\n> >> those most people usually track origin/master with most of their topics.\n> >\n> > That's an unsupported assumption.\n> >\n> > As I showed above, most pople track the branch they push to, not\n> > origin/master.\n> >\n> > Google \"git branch -v\", and you will find mostly official documentation\n> > and man pages.\n> >\n> > Google \"git branch -vv\", and you will find mostly blog posts, Stack\n> > Overflow questions, and cheat sheets.\n> >\n> > I think the reason why is obvious.\n> \n> Yes, I stand corrected.\n> \n> For what it's worth I think one thing to salvage from my ill-informed\n> rambling is that I was under that impression because I set\n> push.default=upstream.\n> \n> But yes, with \"simple\" being the default and refusing to have\n> avar/my-topic have an upstream of origin/master my setup is probably not\n> the common case.\n\nThis is one of the reasons I force myself to have a .gitconfig as clean\nas possible; to try to emulate as much as possible the experience of the\ntypical git user.\n\nHaving used push.default=simple for many years now, I find it very\nsuboptimal. Basically I can't trust git to do the right thing, and I\nalways specify what to push.\n\nI suspect this is what most users do (unless they have setup upstream\nlike `git push -u`).\n\nFor what it's worth, when there's a difference of opinion in the mailing\nlist sometimes I create polls in reddit to see what the users think, and\nI did for this one:\n\nhttps://www.reddit.com/r/git/comments/nuf3p5/where_do_you_point_your_upstream_branch_to/\n\nAt the moment 13 people say they use origin/master, 11 repo/branch, and\n11 say they it's the same thing in their case (e.g. origin/dev).\n8 people don't know what an upstream branch is.\n\n> I wonder if this should depend on the setting of push.default, or\n> whether we can infer anything at all from that setting. After all you\n> can set it to whatever and then either manually do \"git push <remote>\n> <src>:<dst>\" (my usual worklow is just \"git push origin HEAD\"), or\n> manually do the \"git rebase origin/master\" or whatever in the case where\n> your upstream is your own topic branch.\n\nI do have a much better solution that makes everything work for all\nconfigurations, but the patches are not ready yet, and I'm certain will\nreceive pushback, just like the last time I sent it.\n\nThis is the first patch, which I don't think has anything to do with\nthe rest of the patches, and can very well stand on its own.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"426645","messageId":"60be6768d74bc_3bc33208cf@natae.notmuch","threadId":"55841","inReplyTo":"87h7i94ola.fsf@evledraar.gmail.com","subject":"Re: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-07T18:37:28Z","receivedAt":"2021-06-07T18:37:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Jun 07 2021, Felipe Contreras wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n\n> >> and I think the commit messages should discuss whether we break this\n> >> promise of having consistent output between \"status\" and \"branch -v\"\n> >> now.\n> >\n> > But we don't with \"branch -vv\".\n> \n> I think the wording there needs to be changed in any case, I'm not sure\n> what it's supposed to mean.\n> \n> I think the \"show the relationship between\" there is referring to the\n> ahead/behind relationship, or maybe it's just speaking more generally\n> about the short (branch -v[-v]) v.s. long (git status) blurb we show\n> about the branch status overall.\n\nI was going to do this, but given than most of my proposals to update the\ndocumentation are rejected (or similar), I think I'll just do the\nminimal changes for now.\n\n-- \nFelipe Contreras"},{"id":"426711","messageId":"YL8KiiGXF8LdGmQ2@coredump.intra.peff.net","threadId":"55841","inReplyTo":"60be41f6473e2_39c0a208f6@natae.notmuch","subject":"Re: [PATCH] branch: make -v useful","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-06-08T06:13:30Z","receivedAt":"2021-06-08T06:13:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 07, 2021 at 10:57:42AM -0500, Felipe Contreras wrote:\n\n> Jeff King wrote:\n> > On Sat, Jun 05, 2021 at 10:18:14PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> > \n> > > As for the proposal, I don't use \"branch -v\" all that much much, so I\n> > > don't have strong knee-jerk feelings on it, but just considering it now\n> > > I'd think that the current default is a fundamentally better\n> > > approximation of what most users would like as a default.\n> > > \n> > > I.e. I think it's fair to say that to the extent that most users have\n> > > topic branches they're part of some pull-request workflow where they're\n> > > always tracking the one upstream they always care about, usually\n> > > origin/master.\n> > \n> > I'm in the same boat. I don't use \"branch -v\" either, but showing the\n> > upstream name wouldn't be at all helpful to me, since it they would all\n> > just be \"origin/master\".\n> \n> But this patch is not for you, it's for the majority of git users.\n\nIn the quoted text above, Ævar mentioned that many users will have a\npull-request workflow tracking one upstream. So no, I don't think it's\njust for me, but anybody with that workflow.\n\nBut of course i also mentioned other workflows, like...\n\n> > (This will vary based on workflow, but the\n> > other common workflow would probably just show \"topic\" being based on\n> > \"origin/topic\").\n> \n> Based on what evidence?\n> \n> As I showed in [1], all the top results when googling \"upstream branch\"\n> show the upstream branch being used in the opposite way: it's set to the\n> place you push to:\n> \n>   git push --set-upstream @ github/my-pull-request\n\nThat's exactly what I was talking about in the quoted text above.  If\nyou use --set-upstream, then your local \"topic\" will track something\nlike \"origin/topic\".\n\n> > So we could document them as: behave as if \"--format=...\" was given on\n> > the command line (unfortunately \"...\" here is a complex set of %(if)\n> > mechanisms, but it would mostly be for reference; nobody would need to\n> > type it).\n> \n> You mean like this?\n> \n>   %(if:notequals=refs/remotes)%(refname:rstrip=-2)%(then)%(if)%(HEAD)%(then)* \u001b[32m%(else)%(if)%(worktreepath)%(then)+ \u001b[36m%(else)  %(end)%(end)%(align:34,left)%(refname:lstrip=2)%(end)\u001b[m %(objectname:short) %(if)%(upstream:track)%(then)%(upstream:track) %(end)%(contents:subject)%(else)  \u001b[31m%(align:34,left)remotes/%(refname:lstrip=2)%(end)\u001b[m%(if)%(symref)%(then) -> %(symref:short)%(else) %(objectname:short) %(contents:subject)%(end)%(end)\n> \n> I don't think that's particularly useful to anyone.\n\nI agree it's hard to follow. It's probably only useful for people who\nwant to modify it to create a custom format (and any documentation could\ncertainly explain it in human-readable terms and then make a mention of\nthe actual code).\n\n> > And then it is not a far leap to change that to: behave as if --format\n> > was set to the value of branch.verboseFormat, and the default of that\n> > config option is \"...\". And then anybody can make \"branch -v\" behave\n> > however they like.\n> \n> I don't think telling users to do `git command --code=\"type here the\n> code you want git to do\"` is very user friendly.\n\nI'm not quite sure what you think I'm proposing, but it's certainly not\nthat people would type in that code on the command line. It's that \"-v\"\nwould be documented to behave _as if_ that code had been used with\n--format.  And then extended to use another format of the user's choice\nfrom a config variable (which could be based on that format, if they so\nchose).\n\nOf course they can do that already with an alias. The only thing I'm\nactually suggesting is making \"-v\" configurable.\n\n> But even if that was implemented, the whole point of this patch is about\n> what the default value of branch.verboseFormat should be.\n\nI'm saying that I find your proposed value for that default to be\nuseless, and I suspect many other users will, too. Which is why making\nit configurable may actually help people.\n\n> Do I need to produce a list of the top 10 Google results of\n> \"git branch -v\" vs. \"git branch -vv\", to show that most people don't\n> find the output of -v useful?\n> \n> Or what kind of evidence would satisfy you?\n\nDon't bother on my account. I have generally found that going more than\none round deep of discussion with you does not lead anywhere productive,\nand I don't intend to continue this thread.\n\n-Peff\n"},{"id":"426726","messageId":"60bf1997b1a72_1a2ac520865@natae.notmuch","threadId":"55841","inReplyTo":"YL8KiiGXF8LdGmQ2@coredump.intra.peff.net","subject":"Re: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-08T07:17:43Z","receivedAt":"2021-06-08T07:18:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Mon, Jun 07, 2021 at 10:57:42AM -0500, Felipe Contreras wrote:\n> > Jeff King wrote:\n> > > On Sat, Jun 05, 2021 at 10:18:14PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > > > As for the proposal, I don't use \"branch -v\" all that much much, so I\n> > > > don't have strong knee-jerk feelings on it, but just considering it now\n> > > > I'd think that the current default is a fundamentally better\n> > > > approximation of what most users would like as a default.\n> > > > \n> > > > I.e. I think it's fair to say that to the extent that most users have\n> > > > topic branches they're part of some pull-request workflow where they're\n> > > > always tracking the one upstream they always care about, usually\n> > > > origin/master.\n> > > \n> > > I'm in the same boat. I don't use \"branch -v\" either, but showing the\n> > > upstream name wouldn't be at all helpful to me, since it they would all\n> > > just be \"origin/master\".\n> > \n> > But this patch is not for you, it's for the majority of git users.\n> \n> In the quoted text above, Ævar mentioned that many users will have a\n> pull-request workflow tracking one upstream.\n\nA pull-request workflow tracks *two* upstreams.\n\nOption 1: track the base:\n\n  git checkout -b fix -t origin/master # like you, Ævar, and me\n\nOption 2: track the branch you push to:\n\n  git push --set-upstream github fix # like apparently most users\n\nIt's two different preferences for the same workflow.\n\n> So no, I don't think it's just for me, but anybody with that workflow.\n> \n> But of course i also mentioned other workflows, like...\n\nNo. The same workflow can have two very different upstreams.\n\n> > > (This will vary based on workflow, but the\n> > > other common workflow would probably just show \"topic\" being based on\n> > > \"origin/topic\").\n> > \n> > Based on what evidence?\n> > \n> > As I showed in [1], all the top results when googling \"upstream branch\"\n> > show the upstream branch being used in the opposite way: it's set to the\n> > place you push to:\n> > \n> >   git push --set-upstream @ github/my-pull-request\n> \n> That's exactly what I was talking about in the quoted text above.  If\n> you use --set-upstream, then your local \"topic\" will track something\n> like \"origin/topic\".\n\nBut it's not origin/topic. I'm not talking about\n`git branch --set-upstream-to`, I'm talking `git *push* --set-upstream`.\n\nGit is a distributed VCS, most people don't have commit access to the\noriginal repository, therefore they push to their personal repository\n(e.g. github fork).\n\nSo their upstream is not origin/topic, it's github-personal-repo/topic.\n\n> > But even if that was implemented, the whole point of this patch is about\n> > what the default value of branch.verboseFormat should be.\n> \n> I'm saying that I find your proposed value for that default to be\n> useless, and I suspect many other users will, too.\n\nExplain how.\n\nIf most people use `git push --set-upstream`, their upstream is most\ndefinitely not origin/master (nor origin/topic).\n\nEven git itself recommends setting the upstream to where they push to:\n\n  fatal: The current branch fix has no upstream branch.\n  To push the current branch and set the remote as upstream, use\n\n      git push --set-upstream origin fix\n\nSo they will get a benefit from seeing the upstream in `git branch -v`.\n\nWould they not?\n\n> > Do I need to produce a list of the top 10 Google results of\n> > \"git branch -v\" vs. \"git branch -vv\", to show that most people don't\n> > find the output of -v useful?\n> > \n> > Or what kind of evidence would satisfy you?\n> \n> Don't bother on my account. I have generally found that going more than\n> one round deep of discussion with you does not lead anywhere productive,\n> and I don't intend to continue this thread.\n\nIf there's no evidence that will ever convince you otherwise, that means\nyou are not interested in actual real users, only in your idea of users.\n\n\nFor the people who are actually interested in what actual users do, I\nran a poll on reddit [1], and so far:\n\n  15: The base branch (e.g. origin/master)\n  15: The branch you push to (e.g. github/my-pull-request)\n\nThey are tied, 50% use the same upstream as you, 50% don't... For the\n*same* workflow.\n\nCheers.\n\n[1] https://www.reddit.com/r/git/comments/nuf3p5/where_do_you_point_your_upstream_branch_to/\n\n-- \nFelipe Contreras"},{"id":"426729","messageId":"YL8b/zUx0ikbqwC6@coredump.intra.peff.net","threadId":"55841","inReplyTo":"60bf1997b1a72_1a2ac520865@natae.notmuch","subject":"Re: [PATCH] branch: make -v useful","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-06-08T07:27:59Z","receivedAt":"2021-06-08T07:28:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 08, 2021 at 02:17:43AM -0500, Felipe Contreras wrote:\n\n> > Don't bother on my account. I have generally found that going more than\n> > one round deep of discussion with you does not lead anywhere productive,\n> > and I don't intend to continue this thread.\n> \n> If there's no evidence that will ever convince you otherwise, that means\n> you are not interested in actual real users, only in your idea of users.\n\nI think you missed the point here. I am not interested in engaging with\n_you_, because I often find it a waste of time. And I choose to do more\nproductive things.\n\n-Peff\n"},{"id":"426732","messageId":"60bf2a2883b54_1a73f820887@natae.notmuch","threadId":"55841","inReplyTo":"YL8b/zUx0ikbqwC6@coredump.intra.peff.net","subject":"Re: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-08T08:28:24Z","receivedAt":"2021-06-08T08:28:28Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Tue, Jun 08, 2021 at 02:17:43AM -0500, Felipe Contreras wrote:\n> \n> > > Don't bother on my account. I have generally found that going more than\n> > > one round deep of discussion with you does not lead anywhere productive,\n> > > and I don't intend to continue this thread.\n> > \n> > If there's no evidence that will ever convince you otherwise, that means\n> > you are not interested in actual real users, only in your idea of users.\n> \n> I think you missed the point here. I am not interested in engaging with\n> _you_, because I often find it a waste of time. And I choose to do more\n> productive things.\n\nThis is a cop-out.\n\nWe are engaging in a discussion in a *public* mailing list, you are not\nenging only with me, you are engaging with a community.\n\nYour response will be read by other people.\n\nI asked you a direct question that other people in the mailing list\nwould benefit from hearing:\n\n  What kind of evidence would satisfy you?\n\nYou do not have to \"engage with me\", but if you are going to object to\na proposal, other people will want to know on what grounds.\n\nYou could say \"to demonstrate X, we would need Y\", and leave the\ndiscussion.\n\nBut to just say \"I don't think X\" is not productive for anyone in the\nmailinst list.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426749","messageId":"AS8PR02MB7302DF058D13CAE11A1086FD9C379@AS8PR02MB7302.eurprd02.prod.outlook.com","threadId":"55841","inReplyTo":"60bf1997b1a72_1a2ac520865@natae.notmuch","subject":"RE: [PATCH] branch: make -v useful","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2021-06-08T09:06:51Z","receivedAt":"2021-06-08T09:06:56Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\n\n > Git is a distributed VCS, most people don't have commit access to the original repository, therefore they push to their personal repository (e.g. github fork).\n\n[RK] When you say \"most people\", do you mean \"most people who are working on open source projects\"?\n\n[RK] I'm working using Git every day, and I pull from the original repository and push back to it. I am working on closed source company projects.\n\nRegards\nRichard.\n\n\n"},{"id":"426750","messageId":"60bf36f24d2e2_1a848720836@natae.notmuch","threadId":"55841","inReplyTo":"AS8PR02MB7302DF058D13CAE11A1086FD9C379@AS8PR02MB7302.eurprd02.prod.outlook.com","subject":"RE: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-08T09:22:58Z","receivedAt":"2021-06-08T09:24:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kerry, Richard wrote:\n> \n>  > Git is a distributed VCS, most people don't have commit access to\n>  > the original repository, therefore they push to their personal\n>  > repository (e.g. github fork).\n> \n> [RK] When you say \"most people\", do you mean \"most people who are\n> working on open source projects\"?\n\nBoth.\n\nTwo-way workflows are present both in open source projects and private\nprojects.\n\nTriangular workflows are present both in open source projects and\nprivate project.\n\n> [RK] I'm working using Git every day, and I pull from the original\n> repository and push back to it. I am working on closed source company\n> projects.\n\nThe triangularity I'm referring to is not per repository, it's per\nbranch.\n\nDo you always push to the same remote branch you pull from?\n\nHow about rebasing or merging? Do you use the same remote branch?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426758","messageId":"AS8PR02MB7302955796AAEF8B9063505E9C379@AS8PR02MB7302.eurprd02.prod.outlook.com","threadId":"55841","inReplyTo":"60bf36f24d2e2_1a848720836@natae.notmuch","subject":"RE: [PATCH] branch: make -v useful","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2021-06-08T11:32:18Z","receivedAt":"2021-06-08T11:32:24Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\n\n-----Original Message-----\nFrom: Felipe Contreras <felipe.contreras@gmail.com> \nSent: 08 June 2021 10:23\nTo: Kerry, Richard <richard.kerry@atos.net>; Felipe Contreras <felipe.contreras@gmail.com>; Jeff King <peff@peff.net>\nCc: Ævar Arnfjörð Bjarmason <avarab@gmail.com>; git@vger.kernel.org; Junio C Hamano <gitster@pobox.com>\nSubject: RE: [PATCH] branch: make -v useful\n\nCaution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.\n\nKerry, Richard wrote:\n> \n>  > Git is a distributed VCS, most people don't have commit access to  \n> > the original repository, therefore they push to their personal  > \n> repository (e.g. github fork).\n> \n> [RK] When you say \"most people\", do you mean \"most people who are \n> working on open source projects\"?\n\nBoth.\n\nTwo-way workflows are present both in open source projects and private projects.\n\nTriangular workflows are present both in open source projects and private project.\n\n> [RK] I'm working using Git every day, and I pull from the original \n> repository and push back to it. I am working on closed source company \n> projects.\n\nThe triangularity I'm referring to is not per repository, it's per branch.\n\nDo you always push to the same remote branch you pull from?\n[RK] Yes.  There are two people doing most of the work , me and one other.  We each mostly:\n[RK]  1.  Are not working on the same things.  Ie we don't generate many conflicts\n[RK]  2.  Pull and push to the same branch.  Ie each of us has a branch that we work on.  He uses \"master\", I have my own (It is a single very long-lived branch - I know that isn't a recommended workflow but that's where we are for the moment)\n\nHow about rebasing or merging? Do you use the same remote branch?\n[RK] Merges are infrequent, but because we are working in different areas, we merge to \"our own\" branch (few conflicts, usually) and push to its remote.\n[RK] I have never yet done a rebase, but need to do so soon as there is work in an area that we have both worked on.  Then it will be pushed to the usual place - ie the two branches mentioned above.\n\n[RK] So basically, no, not triangular at all, if I understand the meaning of triangular (pull and push to different remotes).\n\nCheers.\n\n--\nFelipe Contreras\n"},{"id":"426943","messageId":"60c18651e2e78_af4cf2086a@natae.notmuch","threadId":"55841","inReplyTo":"AS8PR02MB7302955796AAEF8B9063505E9C379@AS8PR02MB7302.eurprd02.prod.outlook.com","subject":"RE: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-10T03:26:09Z","receivedAt":"2021-06-10T03:26:28Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kerry, Richard wrote:\n> > Do you always push to the same remote branch you pull from?\n\n> [RK] Yes.  There are two people doing most of the work , me and one other.  We each mostly:\n> [RK]  1.  Are not working on the same things.  Ie we don't generate many conflicts\n> [RK]  2.  Pull and push to the same branch.  Ie each of us has a branch that we work on.  He uses \"master\", I have my own (It is a single very long-lived branch - I know that isn't a recommended workflow but that's where we are for the moment)\n\nI call this a two-way workflow.\n\nIf I understand correctly each of you have your own branch, but you both\npull and push to your corresponding branch (he to his branch, you to\nyour branch).\n\n> > How about rebasing or merging? Do you use the same remote branch?\n\n> [RK] Merges are infrequent, but because we are working in different areas, we merge to \"our own\" branch (few conflicts, usually) and push to its remote.\n\nThis is crucial. Is the local and remote branch always the same?\n\nIn other words: do you always pull from \"origin/topic\", and push to\n\"topic\"?\n\nOr do you sometimes pull from another branch?\n\n> [RK] I have never yet done a rebase, but need to do so soon as there is work in an area that we have both worked on.  Then it will be pushed to the usual place - ie the two branches mentioned above.\n\nWhen you involve another branch is sounds like you will be in a\ntriangular workflow.\n\nYou would be fetching from remote branch B, merging to local branch A,\nand pushing to a remote branch A.\n\n> [RK] So basically, no, not triangular at all, if I understand the meaning of triangular (pull and push to different remotes).\n\nNo, once again: triangular workflow doesn't necessarily involve a\ndifferent remote (although it usually does).\n\nYou can pull from branch B from a central repository, and push to branch\nA from the same repository, and that would be triangular, not two-way.\n\n\nIt's understandable that users are confused about this--since in fact\nmany developers are confused too. It would be nice if git had some\ndocumentation about the different workflows, alas it doesn't at the\nmoment.\n\nBasically in my view there are four workflows:\n\n  1. Central - two-way: push and pull the same branches from the same\n     repo.\n  2. Distributed - two-way: push and pull the same branches, but from\n     different repositories (master <-> origin/master,\n     topic <-> github/topic)\n  3. Central - triangular: push and pull different branches from the\n     same repo.\n  4. Distributed - triangular: push and pull different branches from\n     different repositories.\n\nIt sounds to me you are mostly in #1, but soon dabbling into #3.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"428466","messageId":"AS8PR02MB7302119463FF6E69A58E82799C069@AS8PR02MB7302.eurprd02.prod.outlook.com","threadId":"55841","inReplyTo":"60c18651e2e78_af4cf2086a@natae.notmuch","subject":"RE: [PATCH] branch: make -v useful","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2021-06-25T15:03:51Z","receivedAt":"2021-06-25T15:04:46Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\n> From: Felipe Contreras <felipe.contreras@gmail.com>\n> Sent: 10 June 2021 04:26\n> \n> Kerry, Richard wrote:\n> > > Do you always push to the same remote branch you pull from?\n> \n> > [RK] Yes.  There are two people doing most of the work , me and one\n> other.  We each mostly:\n> > [RK]  1.  Are not working on the same things.  Ie we don't generate\n> > many conflicts [RK]  2.  Pull and push to the same branch.  Ie each of\n> > us has a branch that we work on.  He uses \"master\", I have my own (It\n> > is a single very long-lived branch - I know that isn't a recommended\n> > workflow but that's where we are for the moment)\n> \n> I call this a two-way workflow.\n \nOk, I'm  not sure I've heard of that.\nBut then I've not looked into options for workflow.  I've just adapted an existing one for Git.\n\n> If I understand correctly each of you have your own branch, but you both pull\n> and push to your corresponding branch (he to his branch, you to your\n> branch).\n\nYes.\n\n> > > How about rebasing or merging? Do you use the same remote branch?\n\nSee below....\n\n> > [RK] Merges are infrequent, but because we are working in different areas,\n> we merge to \"our own\" branch (few conflicts, usually) and push to its\n> remote.\n> \n> This is crucial. \n\nIs it ?\n\n> Is the local and remote branch always the same?\n\nYes.\n\n> In other words: do you always pull from \"origin/topic\", and push to \"topic\"?\n\nYes.\n\n> Or do you sometimes pull from another branch?\n\nNo.  Just the same one each time.\nThen occasionally merging to reconcile any areas where we have touched the same files.\n\n> > [RK] I have never yet done a rebase, but need to do so soon as there is\n> work in an area that we have both worked on.  Then it will be pushed to the\n> usual place - ie the two branches mentioned above.\n> \n> When you involve another branch is sounds like you will be in a triangular\n> workflow.\n> \n> You would be fetching from remote branch B, merging to local branch A, and\n> pushing to a remote branch A.\n> \n> > [RK] So basically, no, not triangular at all, if I understand the meaning of\n> triangular (pull and push to different remotes).\n> \n> No, once again: triangular workflow doesn't necessarily involve a different\n> remote (although it usually does).\n> \n> You can pull from branch B from a central repository, and push to branch A\n> from the same repository, and that would be triangular, not two-way.\n> \n> \n> It's understandable that users are confused about this--since in fact many\n> developers are confused too. It would be nice if git had some documentation\n> about the different workflows, alas it doesn't at the moment.\n> \n> Basically in my view there are four workflows:\n> \n>   1. Central - two-way: push and pull the same branches from the same\n>      repo.\n>   2. Distributed - two-way: push and pull the same branches, but from\n>      different repositories (master <-> origin/master,\n>      topic <-> github/topic)\n>   3. Central - triangular: push and pull different branches from the\n>      same repo.\n>   4. Distributed - triangular: push and pull different branches from\n>      different repositories.\n> \n> It sounds to me you are mostly in #1, but soon dabbling into #3.\n \nI think we are just doing #1.\nWe moved a few years ago from Subversion to Git.  Before that we were on CVS (actually CVSNT).  Those are centralized, with merging and branches allowed, but not different repos.\nOriginally all the work produced a single final product installer.  Since my work and his turned out to be on different release cycles it was changed so now there are two separate products.\nMy part has some dependencies on his, so I need occasionally to incorporate his changes into my branch.\nI occasionally changes files that will go into his final product, so there is then the occasional merge from my branch to his.\n\nActually maybe there is some #3.\nAfter merging his to mine, then mine back to his, I will push both.  Does that make it #3?\n\n> Cheers.\n> \n> Felipe Contreras\n\nRegards,\nRichard.\n\n"},{"id":"428484","messageId":"60d5fe6c5be64_c237208ae@natae.notmuch","threadId":"55841","inReplyTo":"AS8PR02MB7302119463FF6E69A58E82799C069@AS8PR02MB7302.eurprd02.prod.outlook.com","subject":"RE: [PATCH] branch: make -v useful","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T16:03:56Z","receivedAt":"2021-06-25T16:04:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kerry, Richard wrote:\n> \n> > From: Felipe Contreras <felipe.contreras@gmail.com>\n> > Sent: 10 June 2021 04:26\n> > \n> > Kerry, Richard wrote:\n> > > > Do you always push to the same remote branch you pull from?\n> > \n> > > [RK] Yes.  There are two people doing most of the work , me and one\n> > other.  We each mostly:\n> > > [RK]  1.  Are not working on the same things.  Ie we don't generate\n> > > many conflicts [RK]  2.  Pull and push to the same branch.  Ie each of\n> > > us has a branch that we work on.  He uses \"master\", I have my own (It\n> > > is a single very long-lived branch - I know that isn't a recommended\n> > > workflow but that's where we are for the moment)\n> > \n> > I call this a two-way workflow.\n>  \n> Ok, I'm  not sure I've heard of that.\n\nYou probably haven't, because I invented it.\n\nJust like in a two-way street cars can go on both directions, in a\ntwo-way branch you push and pull from the same destination.\n\n> > > [RK] Merges are infrequent, but because we are working in different areas,\n> > we merge to \"our own\" branch (few conflicts, usually) and push to its\n> > remote.\n> > \n> > This is crucial. \n> \n> Is it ?\n> \n> > Is the local and remote branch always the same?\n> \n> Yes.\n> \n> > In other words: do you always pull from \"origin/topic\", and push to \"topic\"?\n> \n> Yes.\n\nThen that's a two-way branch.\n\n> > > [RK] I have never yet done a rebase, but need to do so soon as there is\n> > work in an area that we have both worked on.  Then it will be pushed to the\n> > usual place - ie the two branches mentioned above.\n> > \n> > When you involve another branch is sounds like you will be in a triangular\n> > workflow.\n> > \n> > You would be fetching from remote branch B, merging to local branch A, and\n> > pushing to a remote branch A.\n> > \n> > > [RK] So basically, no, not triangular at all, if I understand the meaning of\n> > triangular (pull and push to different remotes).\n> > \n> > No, once again: triangular workflow doesn't necessarily involve a different\n> > remote (although it usually does).\n> > \n> > You can pull from branch B from a central repository, and push to branch A\n> > from the same repository, and that would be triangular, not two-way.\n> > \n> > \n> > It's understandable that users are confused about this--since in fact many\n> > developers are confused too. It would be nice if git had some documentation\n> > about the different workflows, alas it doesn't at the moment.\n> > \n> > Basically in my view there are four workflows:\n> > \n> >   1. Central - two-way: push and pull the same branches from the same\n> >      repo.\n> >   2. Distributed - two-way: push and pull the same branches, but from\n> >      different repositories (master <-> origin/master,\n> >      topic <-> github/topic)\n> >   3. Central - triangular: push and pull different branches from the\n> >      same repo.\n> >   4. Distributed - triangular: push and pull different branches from\n> >      different repositories.\n> > \n> > It sounds to me you are mostly in #1, but soon dabbling into #3.\n>  \n> I think we are just doing #1.\n> We moved a few years ago from Subversion to Git.  Before that we were on CVS (actually CVSNT).  Those are centralized, with merging and branches allowed, but not different repos.\n> Originally all the work produced a single final product installer.  Since my work and his turned out to be on different release cycles it was changed so now there are two separate products.\n> My part has some dependencies on his, so I need occasionally to incorporate his changes into my branch.\n> I occasionally changes files that will go into his final product, so there is then the occasional merge from my branch to his.\n> \n> Actually maybe there is some #3.\n> After merging his to mine, then mine back to his, I will push both.  Does that make it #3?\n\nYes, you sometimes use a triangular workflow: pull from your branch,\npush to his branch. Even though it's on the same repository.\n\nEither way, you probably always configure the upstream branch to be your\nbranch, so you always know what your local \"topic\" points to on the\nremote.\n\n-- \nFelipe Contreras\n"}]}