| Message ID | 20210605011339.2202-1-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | branch: make -v useful | expand |
On Fri, Jun 04 2021, Felipe Contreras wrote: > Currently `git branch -v` shows something like "[ahead 10]", but ahead > of what? > > We git experts know ahead of what, but not what that what is set to. Just > like "[@{upstream}: ahead 10]" would not be particularly useful to > anyone that doesn't know, or remembers, what @{upstream} is set to. > > On the other hand "[master: ahead 10]" is perfectly clear to anyone. > > This confusion only gets worse when you see "[ahead 10, behind 100]". Is > it master? Is it next? Is it > john/experimental-feature-i-based-my-branch-on? > > Inevitably most users will need to know what @{upstream} is. > > So let's make `git branch -v` output what is most useful: > > [master] > > Before: > > * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful > > After: > > * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful > Having applied this patch I find the description a bit confusing. The example led me to believe that you'd stripped the remote name, so the common case of "origin/master" would become "master", but instead the example is from a "fc/branch/sane-colors" branch where your "remote tracking branch" is actually tracking your *local* master, i.e. "remote = ."? Disambiguating that is one of the reasons we prefix with the remote name, but I'd say it makes for a confusing example in a commit message, and also if instead of saying: branch: make -v useful It said e.g.: branch: reverse the priority of what -v and -vv show Or something similar to note that it's not "useful" now, but an opinionated change about what we should show on verbosity level 1 and 2. In any case, this proposed patch is missing a doc update, in git-branch.txt we say both: When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print the path of the linked worktree (if any) and the name of the upstream branch, as well (see also git remote show <remote>). And later, for the --track option: When creating a new branch, set up branch.<name>.remote and branch.<name>.merge configuration entries to mark the start-point branch as "upstream" from the new branch. This configuration will tell git to show the relationship between the two branches in git status and git branch -v. Both of those need to be updated, and I think the commit messages should discuss whether we break this promise of having consistent output between "status" and "branch -v" now. 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. 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. Whereas you are presumably tracking origin/master for some, building on your own topic (or other people's topics) for another etc., I think that workflow is much rarer outside of linux.git and git.git, and even for those most people usually track origin/master with most of their topics. > An additional benefit is that `git branch -v` is slightly faster: 30ms > vs. 60ms on my system. 110ms v.s. 5000ms on my system. Lots of old uncleaned-up topics. For what it's worth I remember some past discussion where it was discussed to have some human-readable cut-off so instead of saying: ahead 2, behind 38741 We'd just fall back on saying "behind lots" once your number of behind reached some limit (which could dynamically compute as a heuristic based on repo size, just like the abbrev length)..
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". (This will vary based on workflow, but the other common workflow would probably just show "topic" being based on "origin/topic"). > 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). 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. It would break scripts that parse "branch -v", of course, but we've been pretty explicit that this is porcelain (and the plumbing option is for-each-ref). > For what it's worth I remember some past discussion where it was > discussed to have some human-readable cut-off so instead of saying: > > ahead 2, behind 38741 > > We'd just fall back on saying "behind lots" once your number of behind > reached some limit (which could dynamically compute as a heuristic based > on repo size, just like the abbrev length).. There's some discussion in the sub-thread starting here: https://lore.kernel.org/git/7b759564-5544-8845-0594-e8342a0b4ba5@gmail.com/ I do like that direction, but it sounds like there's some complexity (maybe less these days if we can rely on having commit-graphs with generation numbers). There is an AHEAD_BEHIND_QUICK flag, but I think it can only be triggered via "git status --no-ahead-behind" (and it's kind of unsatisfying, as it only tells you whether the two tips are identical or not). -Peff
Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 04 2021, Felipe Contreras wrote: > > > Currently `git branch -v` shows something like "[ahead 10]", but ahead > > of what? > > > > We git experts know ahead of what, but not what that what is set to. Just > > like "[@{upstream}: ahead 10]" would not be particularly useful to > > anyone that doesn't know, or remembers, what @{upstream} is set to. > > > > On the other hand "[master: ahead 10]" is perfectly clear to anyone. > > > > This confusion only gets worse when you see "[ahead 10, behind 100]". Is > > it master? Is it next? Is it > > john/experimental-feature-i-based-my-branch-on? > > > > Inevitably most users will need to know what @{upstream} is. > > > > So let's make `git branch -v` output what is most useful: > > > > [master] > > > > Before: > > > > * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful > > > > After: > > > > * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful > > > > Having applied this patch I find the description a bit confusing. The > example led me to believe that you'd stripped the remote name, so the > common case of "origin/master" would become "master", but instead the > example is from a "fc/branch/sane-colors" branch where your "remote > tracking branch" is actually tracking your *local* master, i.e. "remote > = ."? Yes, in my particular setup I have a local "master" and many branches based on it. A simply picked a real example. But yeah, it would have been clearer with origin/master. > Disambiguating that is one of the reasons we prefix with the remote > name, but I'd say it makes for a confusing example in a commit message, > and also if instead of saying: > > branch: make -v useful > > It said e.g.: > > branch: reverse the priority of what -v and -vv show I guess that depends on what you consider this patch is doing, why, and how. But I have no problem with your version. > Or something similar to note that it's not "useful" now, but an > opinionated change about what we should show on verbosity level 1 and 2. I'm not sure I parsed that correctly, but that's the whole point: verbosity level 1 is not very useful (I'd argue not useful at all). > In any case, this proposed patch is missing a doc update, in > git-branch.txt we say both: > > When in list mode, show sha1 and commit subject line for each head, > along with relationship to upstream branch (if any). If given twice, > print the path of the linked worktree (if any) and the name of the > upstream branch, as well (see also git remote show <remote>). > > And later, for the --track option: > > When creating a new branch, set up branch.<name>.remote and > branch.<name>.merge configuration entries to mark the start-point > branch as "upstream" from the new branch. This configuration will > tell git to show the relationship between the two branches in git > status and git branch -v. > > Both of those need to be updated, Sure, I missed that. > and I think the commit messages should discuss whether we break this > promise of having consistent output between "status" and "branch -v" > now. But we don't with "branch -vv". > 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. Because git has poor support for triangular workflows users are forced to pick between one of two approaches: 1. If you rebase a lot you pick origin/master 2. If you push a lot you pick github/my-pull-request There's a reason `git push --set-upstream` exists. A quick Google search shows these top results: 1. https://devconnected.com/how-to-set-upstream-branch-on-git/ * git push --set-upstream <remote> <branch> * git branch -vv The author doesn't even mention any other way to setup branches, and of course doesn't bother himself with `git branch -v`, which is not useful at all for his purposes. 2. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches If you want to see what tracking branches you have set up, you can use the -vv option to git branch. This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both. Once again another author that doesn't bother himself with `git branch -v`. And the examples show why: iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new In only one example is the upstream branch origin/master. 3. https://stackoverflow.com/questions/1783405/how-do-i-check-out-a-remote-git-branch The top answer to "How do I check out a remote Git branch?" mentions: git checkout -t <name of remote>/test This most certainly will not create an origin/master upstream. 4. https://www.git-tower.com/learn/git/faq/track-remote-upstream-branch/ git checkout --track origin/dev git push -u origin dev git branch -u origin/dev Once again no sight of origin/master, which isn't even mentioned in the whole article. So no, I don't think it's accurate to say that most people would track origin/master, in fact, I would say of the people that know how to set upstream tracking branches, the minority would pick origin/master. > The -v output showing the ahead/behind relationship to that branch What branch? If I show you the output of my `git branch -v` on git.git do you think you would be able to figure out what branch is being tracked? Not even I could figure that out. > Whereas you are presumably tracking origin/master for some, building on > your own topic (or other people's topics) for another etc., I think that > workflow is much rarer outside of linux.git and git.git, and even for > those most people usually track origin/master with most of their topics. That's an unsupported assumption. As I showed above, most pople track the branch they push to, not origin/master. Google "git branch -v", and you will find mostly official documentation and man pages. Google "git branch -vv", and you will find mostly blog posts, Stack Overflow questions, and cheat sheets. I think the reason why is obvious. Cheers.
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/
On Mon, Jun 07 2021, Felipe Contreras wrote: > Ævar Arnfjörð Bjarmason wrote: >> On Fri, Jun 04 2021, Felipe Contreras wrote: >> >> > Currently `git branch -v` shows something like "[ahead 10]", but ahead >> > of what? >> > >> > We git experts know ahead of what, but not what that what is set to. Just >> > like "[@{upstream}: ahead 10]" would not be particularly useful to >> > anyone that doesn't know, or remembers, what @{upstream} is set to. >> > >> > On the other hand "[master: ahead 10]" is perfectly clear to anyone. >> > >> > This confusion only gets worse when you see "[ahead 10, behind 100]". Is >> > it master? Is it next? Is it >> > john/experimental-feature-i-based-my-branch-on? >> > >> > Inevitably most users will need to know what @{upstream} is. >> > >> > So let's make `git branch -v` output what is most useful: >> > >> > [master] >> > >> > Before: >> > >> > * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful >> > >> > After: >> > >> > * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful >> > >> >> Having applied this patch I find the description a bit confusing. The >> example led me to believe that you'd stripped the remote name, so the >> common case of "origin/master" would become "master", but instead the >> example is from a "fc/branch/sane-colors" branch where your "remote >> tracking branch" is actually tracking your *local* master, i.e. "remote >> = ."? > > Yes, in my particular setup I have a local "master" and many branches > based on it. A simply picked a real example. > > But yeah, it would have been clearer with origin/master. *nod* >> Disambiguating that is one of the reasons we prefix with the remote >> name, but I'd say it makes for a confusing example in a commit message, >> and also if instead of saying: >> >> branch: make -v useful >> >> It said e.g.: >> >> branch: reverse the priority of what -v and -vv show > > I guess that depends on what you consider this patch is doing, why, and how. > > But I have no problem with your version. > >> Or something similar to note that it's not "useful" now, but an >> opinionated change about what we should show on verbosity level 1 and 2. > > I'm not sure I parsed that correctly, but that's the whole point: > verbosity level 1 is not very useful (I'd argue not useful at all). Maybe, anyway I meant to suggest saying something approaching "reverse the order of the data we consider important" instead of the equivalent of "make the data useful". >> In any case, this proposed patch is missing a doc update, in >> git-branch.txt we say both: >> >> When in list mode, show sha1 and commit subject line for each head, >> along with relationship to upstream branch (if any). If given twice, >> print the path of the linked worktree (if any) and the name of the >> upstream branch, as well (see also git remote show <remote>). >> >> And later, for the --track option: >> >> When creating a new branch, set up branch.<name>.remote and >> branch.<name>.merge configuration entries to mark the start-point >> branch as "upstream" from the new branch. This configuration will >> tell git to show the relationship between the two branches in git >> status and git branch -v. >> >> Both of those need to be updated, > > Sure, I missed that. > >> and I think the commit messages should discuss whether we break this >> promise of having consistent output between "status" and "branch -v" >> now. > > But we don't with "branch -vv". I think the wording there needs to be changed in any case, I'm not sure what it's supposed to mean. I think the "show the relationship between" there is referring to the ahead/behind relationship, or maybe it's just speaking more generally about the short (branch -v[-v]) v.s. long (git status) blurb we show about the branch status overall. >> 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. > > Because git has poor support for triangular workflows users are forced > to pick between one of two approaches: > > 1. If you rebase a lot you pick origin/master > 2. If you push a lot you pick github/my-pull-request > > There's a reason `git push --set-upstream` exists. > > A quick Google search shows these top results: > > 1. https://devconnected.com/how-to-set-upstream-branch-on-git/ > > * git push --set-upstream <remote> <branch> > * git branch -vv > > The author doesn't even mention any other way to setup branches, and of > course doesn't bother himself with `git branch -v`, which is not useful > at all for his purposes. > > 2. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches > > If you want to see what tracking branches you have set up, you can use > the -vv option to git branch. This will list out your local branches > with more information including what each branch is tracking and if > your local branch is ahead, behind or both. > > Once again another author that doesn't bother himself with > `git branch -v`. > > And the examples show why: > > iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets > master 1ae2a45 [origin/master] Deploy index fix > * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it > testing 5ea463a Try something new > > In only one example is the upstream branch origin/master. > > 3. https://stackoverflow.com/questions/1783405/how-do-i-check-out-a-remote-git-branch > > The top answer to "How do I check out a remote Git branch?" mentions: > > git checkout -t <name of remote>/test > > This most certainly will not create an origin/master upstream. > > 4. https://www.git-tower.com/learn/git/faq/track-remote-upstream-branch/ > > git checkout --track origin/dev > git push -u origin dev > git branch -u origin/dev > > Once again no sight of origin/master, which isn't even mentioned in the > whole article. > > > So no, I don't think it's accurate to say that most people would track > origin/master, in fact, I would say of the people that know how to set > upstream tracking branches, the minority would pick origin/master. > >> The -v output showing the ahead/behind relationship to that branch > > What branch? > > If I show you the output of my `git branch -v` on git.git do you think you > would be able to figure out what branch is being tracked? Not even I > could figure that out. > >> Whereas you are presumably tracking origin/master for some, building on >> your own topic (or other people's topics) for another etc., I think that >> workflow is much rarer outside of linux.git and git.git, and even for >> those most people usually track origin/master with most of their topics. > > That's an unsupported assumption. > > As I showed above, most pople track the branch they push to, not > origin/master. > > Google "git branch -v", and you will find mostly official documentation > and man pages. > > Google "git branch -vv", and you will find mostly blog posts, Stack > Overflow questions, and cheat sheets. > > I think the reason why is obvious. Yes, I stand corrected. For what it's worth I think one thing to salvage from my ill-informed rambling is that I was under that impression because I set push.default=upstream. But yes, with "simple" being the default and refusing to have avar/my-topic have an upstream of origin/master my setup is probably not the common case. I wonder if this should depend on the setting of push.default, or whether we can infer anything at all from that setting. After all you can set it to whatever and then either manually do "git push <remote> <src>:<dst>" (my usual worklow is just "git push origin HEAD"), or manually do the "git rebase origin/master" or whatever in the case where your upstream is your own topic branch.
Ævar Arnfjörð Bjarmason wrote: > On Mon, Jun 07 2021, Felipe Contreras wrote: > > Ævar Arnfjörð Bjarmason wrote: > >> Disambiguating that is one of the reasons we prefix with the remote > >> name, but I'd say it makes for a confusing example in a commit message, > >> and also if instead of saying: > >> > >> branch: make -v useful > >> > >> It said e.g.: > >> > >> branch: reverse the priority of what -v and -vv show > > > > I guess that depends on what you consider this patch is doing, why, and how. > > > > But I have no problem with your version. > > > >> Or something similar to note that it's not "useful" now, but an > >> opinionated change about what we should show on verbosity level 1 and 2. > > > > I'm not sure I parsed that correctly, but that's the whole point: > > verbosity level 1 is not very useful (I'd argue not useful at all). > > Maybe, anyway I meant to suggest saying something approaching "reverse > the order of the data we consider important" instead of the equivalent > of "make the data useful". All right, that transmits the message I want to transmit and is less abrasive, so that's good. I've updated the title, and in fact changed the whole commit message. > >> Whereas you are presumably tracking origin/master for some, building on > >> your own topic (or other people's topics) for another etc., I think that > >> workflow is much rarer outside of linux.git and git.git, and even for > >> those most people usually track origin/master with most of their topics. > > > > That's an unsupported assumption. > > > > As I showed above, most pople track the branch they push to, not > > origin/master. > > > > Google "git branch -v", and you will find mostly official documentation > > and man pages. > > > > Google "git branch -vv", and you will find mostly blog posts, Stack > > Overflow questions, and cheat sheets. > > > > I think the reason why is obvious. > > Yes, I stand corrected. > > For what it's worth I think one thing to salvage from my ill-informed > rambling is that I was under that impression because I set > push.default=upstream. > > But yes, with "simple" being the default and refusing to have > avar/my-topic have an upstream of origin/master my setup is probably not > the common case. This is one of the reasons I force myself to have a .gitconfig as clean as possible; to try to emulate as much as possible the experience of the typical git user. Having used push.default=simple for many years now, I find it very suboptimal. Basically I can't trust git to do the right thing, and I always specify what to push. I suspect this is what most users do (unless they have setup upstream like `git push -u`). For what it's worth, when there's a difference of opinion in the mailing list sometimes I create polls in reddit to see what the users think, and I did for this one: https://www.reddit.com/r/git/comments/nuf3p5/where_do_you_point_your_upstream_branch_to/ At the moment 13 people say they use origin/master, 11 repo/branch, and 11 say they it's the same thing in their case (e.g. origin/dev). 8 people don't know what an upstream branch is. > I wonder if this should depend on the setting of push.default, or > whether we can infer anything at all from that setting. After all you > can set it to whatever and then either manually do "git push <remote> > <src>:<dst>" (my usual worklow is just "git push origin HEAD"), or > manually do the "git rebase origin/master" or whatever in the case where > your upstream is your own topic branch. I do have a much better solution that makes everything work for all configurations, but the patches are not ready yet, and I'm certain will receive pushback, just like the last time I sent it. This is the first patch, which I don't think has anything to do with the rest of the patches, and can very well stand on its own. Cheers.
Ævar Arnfjörð Bjarmason wrote: > On Mon, Jun 07 2021, Felipe Contreras wrote: > > Ævar Arnfjörð Bjarmason wrote: > >> and I think the commit messages should discuss whether we break this > >> promise of having consistent output between "status" and "branch -v" > >> now. > > > > But we don't with "branch -vv". > > I think the wording there needs to be changed in any case, I'm not sure > what it's supposed to mean. > > I think the "show the relationship between" there is referring to the > ahead/behind relationship, or maybe it's just speaking more generally > about the short (branch -v[-v]) v.s. long (git status) blurb we show > about the branch status overall. I was going to do this, but given than most of my proposals to update the documentation are rejected (or similar), I think I'll just do the minimal changes for now.
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
Jeff King wrote: > 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. A pull-request workflow tracks *two* upstreams. Option 1: track the base: git checkout -b fix -t origin/master # like you, Ævar, and me Option 2: track the branch you push to: git push --set-upstream github fix # like apparently most users It's two different preferences for the same workflow. > 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... No. The same workflow can have two very different upstreams. > > > (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". But it's not origin/topic. I'm not talking about `git branch --set-upstream-to`, I'm talking `git *push* --set-upstream`. 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). So their upstream is not origin/topic, it's github-personal-repo/topic. > > 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. Explain how. If most people use `git push --set-upstream`, their upstream is most definitely not origin/master (nor origin/topic). Even git itself recommends setting the upstream to where they push to: fatal: The current branch fix has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin fix So they will get a benefit from seeing the upstream in `git branch -v`. Would they not? > > 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. If there's no evidence that will ever convince you otherwise, that means you are not interested in actual real users, only in your idea of users. For the people who are actually interested in what actual users do, I ran a poll on reddit [1], and so far: 15: The base branch (e.g. origin/master) 15: The branch you push to (e.g. github/my-pull-request) They are tied, 50% use the same upstream as you, 50% don't... For the *same* workflow. Cheers. [1] https://www.reddit.com/r/git/comments/nuf3p5/where_do_you_point_your_upstream_branch_to/
On Tue, Jun 08, 2021 at 02:17:43AM -0500, Felipe Contreras wrote: > > 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. > > If there's no evidence that will ever convince you otherwise, that means > you are not interested in actual real users, only in your idea of users. I think you missed the point here. I am not interested in engaging with _you_, because I often find it a waste of time. And I choose to do more productive things. -Peff
Jeff King wrote: > On Tue, Jun 08, 2021 at 02:17:43AM -0500, Felipe Contreras wrote: > > > > 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. > > > > If there's no evidence that will ever convince you otherwise, that means > > you are not interested in actual real users, only in your idea of users. > > I think you missed the point here. I am not interested in engaging with > _you_, because I often find it a waste of time. And I choose to do more > productive things. This is a cop-out. We are engaging in a discussion in a *public* mailing list, you are not enging only with me, you are engaging with a community. Your response will be read by other people. I asked you a direct question that other people in the mailing list would benefit from hearing: What kind of evidence would satisfy you? You do not have to "engage with me", but if you are going to object to a proposal, other people will want to know on what grounds. You could say "to demonstrate X, we would need Y", and leave the discussion. But to just say "I don't think X" is not productive for anyone in the mailinst list. Cheers.
> 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).
[RK] When you say "most people", do you mean "most people who are working on open source projects"?
[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.
Regards
Richard.
Kerry, Richard wrote: > > > 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). > > [RK] When you say "most people", do you mean "most people who are > working on open source projects"? Both. Two-way workflows are present both in open source projects and private projects. Triangular workflows are present both in open source projects and private project. > [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. The triangularity I'm referring to is not per repository, it's per branch. Do you always push to the same remote branch you pull from? How about rebasing or merging? Do you use the same remote branch? Cheers.
-----Original Message----- From: Felipe Contreras <felipe.contreras@gmail.com> Sent: 08 June 2021 10:23 To: Kerry, Richard <richard.kerry@atos.net>; Felipe Contreras <felipe.contreras@gmail.com>; Jeff King <peff@peff.net> Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com>; git@vger.kernel.org; Junio C Hamano <gitster@pobox.com> Subject: RE: [PATCH] branch: make -v useful Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. Kerry, Richard wrote: > > > 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). > > [RK] When you say "most people", do you mean "most people who are > working on open source projects"? Both. Two-way workflows are present both in open source projects and private projects. Triangular workflows are present both in open source projects and private project. > [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. The triangularity I'm referring to is not per repository, it's per branch. Do you always push to the same remote branch you pull from? [RK] Yes. There are two people doing most of the work , me and one other. We each mostly: [RK] 1. Are not working on the same things. Ie we don't generate many conflicts [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) How about rebasing or merging? Do you use the same remote branch? [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. [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. [RK] So basically, no, not triangular at all, if I understand the meaning of triangular (pull and push to different remotes). Cheers. -- Felipe Contreras
Kerry, Richard wrote: > > Do you always push to the same remote branch you pull from? > [RK] Yes. There are two people doing most of the work , me and one other. We each mostly: > [RK] 1. Are not working on the same things. Ie we don't generate many conflicts > [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) I call this a two-way workflow. If I understand correctly each of you have your own branch, but you both pull and push to your corresponding branch (he to his branch, you to your branch). > > How about rebasing or merging? Do you use the same remote branch? > [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. This is crucial. Is the local and remote branch always the same? In other words: do you always pull from "origin/topic", and push to "topic"? Or do you sometimes pull from another branch? > [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. When you involve another branch is sounds like you will be in a triangular workflow. You would be fetching from remote branch B, merging to local branch A, and pushing to a remote branch A. > [RK] So basically, no, not triangular at all, if I understand the meaning of triangular (pull and push to different remotes). No, once again: triangular workflow doesn't necessarily involve a different remote (although it usually does). You can pull from branch B from a central repository, and push to branch A from the same repository, and that would be triangular, not two-way. It's understandable that users are confused about this--since in fact many developers are confused too. It would be nice if git had some documentation about the different workflows, alas it doesn't at the moment. Basically in my view there are four workflows: 1. Central - two-way: push and pull the same branches from the same repo. 2. Distributed - two-way: push and pull the same branches, but from different repositories (master <-> origin/master, topic <-> github/topic) 3. Central - triangular: push and pull different branches from the same repo. 4. Distributed - triangular: push and pull different branches from different repositories. It sounds to me you are mostly in #1, but soon dabbling into #3. Cheers.
> From: Felipe Contreras <felipe.contreras@gmail.com> > Sent: 10 June 2021 04:26 > > Kerry, Richard wrote: > > > Do you always push to the same remote branch you pull from? > > > [RK] Yes. There are two people doing most of the work , me and one > other. We each mostly: > > [RK] 1. Are not working on the same things. Ie we don't generate > > many conflicts [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) > > I call this a two-way workflow. Ok, I'm not sure I've heard of that. But then I've not looked into options for workflow. I've just adapted an existing one for Git. > If I understand correctly each of you have your own branch, but you both pull > and push to your corresponding branch (he to his branch, you to your > branch). Yes. > > > How about rebasing or merging? Do you use the same remote branch? See below.... > > [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. > > This is crucial. Is it ? > Is the local and remote branch always the same? Yes. > In other words: do you always pull from "origin/topic", and push to "topic"? Yes. > Or do you sometimes pull from another branch? No. Just the same one each time. Then occasionally merging to reconcile any areas where we have touched the same files. > > [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. > > When you involve another branch is sounds like you will be in a triangular > workflow. > > You would be fetching from remote branch B, merging to local branch A, and > pushing to a remote branch A. > > > [RK] So basically, no, not triangular at all, if I understand the meaning of > triangular (pull and push to different remotes). > > No, once again: triangular workflow doesn't necessarily involve a different > remote (although it usually does). > > You can pull from branch B from a central repository, and push to branch A > from the same repository, and that would be triangular, not two-way. > > > It's understandable that users are confused about this--since in fact many > developers are confused too. It would be nice if git had some documentation > about the different workflows, alas it doesn't at the moment. > > Basically in my view there are four workflows: > > 1. Central - two-way: push and pull the same branches from the same > repo. > 2. Distributed - two-way: push and pull the same branches, but from > different repositories (master <-> origin/master, > topic <-> github/topic) > 3. Central - triangular: push and pull different branches from the > same repo. > 4. Distributed - triangular: push and pull different branches from > different repositories. > > It sounds to me you are mostly in #1, but soon dabbling into #3. I think we are just doing #1. 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. 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. My part has some dependencies on his, so I need occasionally to incorporate his changes into my branch. I occasionally changes files that will go into his final product, so there is then the occasional merge from my branch to his. Actually maybe there is some #3. After merging his to mine, then mine back to his, I will push both. Does that make it #3? > Cheers. > > Felipe Contreras Regards, Richard.
Kerry, Richard wrote: > > > From: Felipe Contreras <felipe.contreras@gmail.com> > > Sent: 10 June 2021 04:26 > > > > Kerry, Richard wrote: > > > > Do you always push to the same remote branch you pull from? > > > > > [RK] Yes. There are two people doing most of the work , me and one > > other. We each mostly: > > > [RK] 1. Are not working on the same things. Ie we don't generate > > > many conflicts [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) > > > > I call this a two-way workflow. > > Ok, I'm not sure I've heard of that. You probably haven't, because I invented it. Just like in a two-way street cars can go on both directions, in a two-way branch you push and pull from the same destination. > > > [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. > > > > This is crucial. > > Is it ? > > > Is the local and remote branch always the same? > > Yes. > > > In other words: do you always pull from "origin/topic", and push to "topic"? > > Yes. Then that's a two-way branch. > > > [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. > > > > When you involve another branch is sounds like you will be in a triangular > > workflow. > > > > You would be fetching from remote branch B, merging to local branch A, and > > pushing to a remote branch A. > > > > > [RK] So basically, no, not triangular at all, if I understand the meaning of > > triangular (pull and push to different remotes). > > > > No, once again: triangular workflow doesn't necessarily involve a different > > remote (although it usually does). > > > > You can pull from branch B from a central repository, and push to branch A > > from the same repository, and that would be triangular, not two-way. > > > > > > It's understandable that users are confused about this--since in fact many > > developers are confused too. It would be nice if git had some documentation > > about the different workflows, alas it doesn't at the moment. > > > > Basically in my view there are four workflows: > > > > 1. Central - two-way: push and pull the same branches from the same > > repo. > > 2. Distributed - two-way: push and pull the same branches, but from > > different repositories (master <-> origin/master, > > topic <-> github/topic) > > 3. Central - triangular: push and pull different branches from the > > same repo. > > 4. Distributed - triangular: push and pull different branches from > > different repositories. > > > > It sounds to me you are mostly in #1, but soon dabbling into #3. > > I think we are just doing #1. > 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. > 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. > My part has some dependencies on his, so I need occasionally to incorporate his changes into my branch. > I occasionally changes files that will go into his final product, so there is then the occasional merge from my branch to his. > > Actually maybe there is some #3. > After merging his to mine, then mine back to his, I will push both. Does that make it #3? Yes, you sometimes use a triangular workflow: pull from your branch, push to his branch. Even though it's on the same repository. Either way, you probably always configure the upstream branch to be your branch, so you always know what your local "topic" points to on the remote.
diff --git a/builtin/branch.c b/builtin/branch.c index b23b1d1752..7c0d3f7e4e 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -375,16 +375,15 @@ static char *build_format(struct ref_filter *filter, int maxwidth, const char *r strbuf_addstr(&local, branch_get_color(BRANCH_COLOR_RESET)); strbuf_addf(&local, " %s ", obname.buf); + strbuf_addf(&local, "%%(if:notequals=*)%%(HEAD)%%(then)%%(if)%%(worktreepath)%%(then)(%s%%(worktreepath)%s) %%(end)%%(end)", + branch_get_color(BRANCH_COLOR_WORKTREE), branch_get_color(BRANCH_COLOR_RESET)); if (filter->verbose > 1) - { - strbuf_addf(&local, "%%(if:notequals=*)%%(HEAD)%%(then)%%(if)%%(worktreepath)%%(then)(%s%%(worktreepath)%s) %%(end)%%(end)", - branch_get_color(BRANCH_COLOR_WORKTREE), branch_get_color(BRANCH_COLOR_RESET)); strbuf_addf(&local, "%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s%%(if)%%(upstream:track)" "%%(then): %%(upstream:track,nobracket)%%(end)] %%(end)%%(contents:subject)", branch_get_color(BRANCH_COLOR_UPSTREAM), branch_get_color(BRANCH_COLOR_RESET)); - } else - strbuf_addf(&local, "%%(if)%%(upstream:track)%%(then)%%(upstream:track) %%(end)%%(contents:subject)"); + strbuf_addf(&local, "%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s] %%(end)%%(contents:subject)", + branch_get_color(BRANCH_COLOR_UPSTREAM), branch_get_color(BRANCH_COLOR_RESET)); strbuf_addf(&remote, "%%(align:%d,left)%s%%(refname:lstrip=2)%%(end)%s" "%%(if)%%(symref)%%(then) -> %%(symref:short)" diff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh index 349a810cee..53e2d65e67 100755 --- a/t/t3201-branch-contains.sh +++ b/t/t3201-branch-contains.sh @@ -261,7 +261,7 @@ test_expect_success 'branch --merged with --verbose' ' git branch --verbose --merged topic >actual && cat >expect <<-EOF && main $(git rev-parse --short main) second on main - * topic $(git rev-parse --short topic ) [ahead 1] foo + * topic $(git rev-parse --short topic ) [main] foo zzz $(git rev-parse --short zzz ) second on main EOF test_cmp expect actual diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh index a313849406..30f80ad61b 100755 --- a/t/t6040-tracking-info.sh +++ b/t/t6040-tracking-info.sh @@ -43,12 +43,12 @@ test_expect_success setup ' t6040_script='s/^..\(b.\) *[0-9a-f]* \(.*\)$/\1 \2/p' cat >expect <<\EOF -b1 [ahead 1, behind 1] d -b2 [ahead 1, behind 1] d -b3 [behind 1] b -b4 [ahead 2] f -b5 [gone] g -b6 c +b1 [origin/main] d +b2 [origin/main] d +b3 [origin/main] b +b4 [origin/main] f +b5 [brokenbase] g +b6 [origin/main] c EOF test_expect_success 'branch -v' '
Currently `git branch -v` shows something like "[ahead 10]", but ahead of what? We git experts know ahead of what, but not what that what is set to. Just like "[@{upstream}: ahead 10]" would not be particularly useful to anyone that doesn't know, or remembers, what @{upstream} is set to. On the other hand "[master: ahead 10]" is perfectly clear to anyone. This confusion only gets worse when you see "[ahead 10, behind 100]". Is it master? Is it next? Is it john/experimental-feature-i-based-my-branch-on? Inevitably most users will need to know what @{upstream} is. So let's make `git branch -v` output what is most useful: [master] Before: * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful After: * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful An additional benefit is that `git branch -v` is slightly faster: 30ms vs. 60ms on my system. `git branch -vv` is unaffected. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- This is a reboot of my old patch series [1]. Every time I use git without this feature I miss it. [1] https://lore.kernel.org/git/1398027514-19399-1-git-send-email-felipe.contreras@gmail.com/ builtin/branch.c | 9 ++++----- t/t3201-branch-contains.sh | 2 +- t/t6040-tracking-info.sh | 12 ++++++------ 3 files changed, 11 insertions(+), 12 deletions(-)