{"thread":{"id":"49902","subject":"Git pull confusing output","startedAt":"2018-11-27T16:52:25Z","lastAt":"2018-11-28T20:27:47Z","messageCount":6,"participants":["Will","Stefan Beller","Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"364138","messageId":"758FA299-0842-4462-8CF6-D7210D26A6C7@gmail.com","threadId":"49902","inReplyTo":null,"subject":"Git pull confusing output","fromName":"Will","fromEmail":"william.duclot@gmail.com","sentAt":"2018-11-27T16:52:09Z","receivedAt":"2018-11-27T16:52:25Z","isPatch":false,"sender":{"key":"william.duclot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/15254996?v=4"},"body":"I’m far from being a guru, but I consider myself a competent Git user. \nYet, here’s my understanding of the output of one the most-used \ncommands, `git push`:\n> Counting objects: 6, done.\nNo idea what an “object” is. Apparently there’s 6 of them here. \nWhat does “counting” them means? Should I care?\n> Delta compression using up to 4 threads.\nNo idea what is “delta compression”, I suppose something is being \ncompressed. It’s using anything between 1 and 4 threads, which is not \na very precise or useful information. Should I care?\n> Compressing objects: 100% (6/6), done.\nI still don’t know what objects are, but I appreciate having feedback \non progress\n> Writing objects: 100% (6/6), 656 bytes | 656.00 KiB/s, done.\nWriting what, where? Should I care? Still good to have feedback\n> Total 6 (delta 4), reused 0 (delta 0)\nNo idea what any of those numbers mean. Should I care?\n> remote: Resolving deltas: 100% (4/4), completed with 4 local objects.\nI do know what’s a remote, but I don’t know what “resolving \ndeltas” means. There’s local objects now? I don’t understand what \nhappened to those local objects, are they the byproduct of the delta \nresolving or the input or something else? Should I care?\n> To github.com:williamdclt/some-repo.git\nFair enough\n> 1ca9aaa..4320d30  master -> master\nFair enough\n\n\nAll in all, I didn’t understand most of what I’ve been told, and \ndon’t seem to care about it. Don’t take my sassiness for disrespect, \nI really appreciate (and am impressed by) everything that happens here, \nbut I feel like a less confusing UI is such a low-hanging fruit. How \nmany devs understand what all of this means, 1%-2% if even that? And \neven them, do they need this info every time they push?\n\nI feel like a less intimidating output would help, while showing info \nabout objects and deltas with the verbose flag:\n> Compressing… done\n> Pushing to github.com:williamdclt/some-repo.git… done\n> 1ca9aaa..4320d30  master -> master\n\n\nI’d be more than happy to work on this (`git push` is an example \namongst so many other), but want the mailing list’s opinion on it. Am \nI wrong in thinking that this output is not something users want, am I \nfighting windmills or maybe just being ignorant?\n"},{"id":"364149","messageId":"CAGZ79kbDHyzFF-HtDcD=rOLZB+RFRnVqZgXb9uwm=9_m-6E0QA@mail.gmail.com","threadId":"49902","inReplyTo":"758FA299-0842-4462-8CF6-D7210D26A6C7@gmail.com","subject":"Re: Git pull confusing output","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-11-27T19:24:56Z","receivedAt":"2018-11-27T19:25:12Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Nov 27, 2018 at 8:52 AM Will <william.duclot@gmail.com> wrote:\n\n> And even them, do they need this info every time they push?\n\nI agree that we should make the output a bit more user friendly,\nwhich means we'd only want to output relevant data for the user.\n\nThe different phases taking each one line takes up precious\nscreen real estate, so another approach would be delete the line\nafter one phase is finished, such that you'd only see the currently\nactive phase (that can be useful for debugging as in \"The phase of\n'Writing objects' takes very long\" -> slow network connection).\n\n> I feel like a less intimidating output would help, while showing info\n> about objects and deltas with the verbose flag:\n\nI agree that most information in pushing is not very useful\nand could be omitted. This helps in multiple ways:\n* it keeps the focus on the actually important information,\n   see bf1a11f0a1 (sideband: highlight keywords in remote\n   sideband output, 2018-08-07)\n* less space in a terminal wasted, such that you can scroll over\n   it better\n\n> > Compressing… done\n\nAfter the push succeeded this information would not be useful\nany more, it is only useful during the compression phase\n(Does it progress quickly enough? or does it error out?)\n\nSlightly related (but applies mostly to fetch, for which this\ndiscussion can also be had):\nWhen fetching, these informations are generated on the\nremote side (as the server needs to create the packfile\naccording to your local state that you negotiated with the\nserver), which takes some time. Sending over this\ninformation also keeps the connection alive. This is only\nrelevant in corner cases depending on the setup of the\nhosting provider/repository, but it led to commits such as\nhttps://eclipse.googlesource.com/jgit/jgit/+/a38531b21c7e2b0dc956e0ed1bfc9513f604273c\nin the java implementation of Git.\n\n> > Pushing to github.com:williamdclt/some-repo.git… done\n> > 1ca9aaa..4320d30  master -> master\n>\n>\n> I’d be more than happy to work on this (`git push` is an example\n> amongst so many other), but want the mailing list’s opinion on it. Am\n> I wrong in thinking that this output is not something users want, am I\n> fighting windmills or maybe just being ignorant?\n\nI think this would be a useful patch, but it could get complicated\nquickly: push uses other low level git commands to prepare the\npackfile to be sent to the server, currently it only needs to pipe\nthrough the output of the low level command (or even have the\nlow level command directly write to the terminal).\n\nThe output of those low level commands should not be changed\nwhen run on their own, I would assume.\n\nSo maybe the best way to dive into understanding what happens\nunder the hood in git-push is to run\n\n  GIT_TRACE=1 git push ...\n\nand see what child processes are invoked (e.g.\nrun_command: git pack-objects --all-progress-implied)\nand then we'd need to change the output of iff the\nspecific progress flag is given.\n\nStefan\n"},{"id":"364167","messageId":"1A9DD0D0-A1CD-44B8-A44A-35D795DA18D1@gmail.com","threadId":"49902","inReplyTo":"CAGZ79kbDHyzFF-HtDcD=rOLZB+RFRnVqZgXb9uwm=9_m-6E0QA@mail.gmail.com","subject":"Re: Git pull confusing output","fromName":"Will","fromEmail":"william.duclot@gmail.com","sentAt":"2018-11-27T22:34:40Z","receivedAt":"2018-11-27T22:34:45Z","isPatch":false,"sender":{"key":"william.duclot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/15254996?v=4"},"body":"\n\nOn 27 Nov 2018, at 19:24, Stefan Beller wrote:\n\n> The different phases taking each one line takes up precious\n> screen real estate, so another approach would be delete the line\n> after one phase is finished, such that you'd only see the currently\n> active phase (that can be useful for debugging as in \"The phase of\n> 'Writing objects' takes very long\" -> slow network connection).\n\nI like this idea\n\n>>> Pushing to github.com:williamdclt/some-repo.git… done\n>>> 1ca9aaa..4320d30  master -> master\n>>\n>>\n>> I’d be more than happy to work on this (`git push` is an example\n>> amongst so many other), but want the mailing list’s opinion on it. Am\n>> I wrong in thinking that this output is not something users want, am I\n>> fighting windmills or maybe just being ignorant?\n>\n> I think this would be a useful patch, but it could get complicated\n> quickly: push uses other low level git commands to prepare the\n> packfile to be sent to the server, currently it only needs to pipe\n> through the output of the low level command (or even have the\n> low level command directly write to the terminal).\n>\n> The output of those low level commands should not be changed\n> when run on their own, I would assume.\n\nAgreed. I didn’t expect it to be so subtle, but I’ll look into it\nand see if that’s something within my reach.\n"},{"id":"364173","messageId":"87h8g2ytwf.fsf@evledraar.gmail.com","threadId":"49902","inReplyTo":"1A9DD0D0-A1CD-44B8-A44A-35D795DA18D1@gmail.com","subject":"Re: Git pull confusing output","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-11-27T23:37:04Z","receivedAt":"2018-11-27T23:37:10Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Nov 27 2018, Will wrote:\n\n> On 27 Nov 2018, at 19:24, Stefan Beller wrote:\n>\n>> The different phases taking each one line takes up precious\n>> screen real estate, so another approach would be delete the line\n>> after one phase is finished, such that you'd only see the currently\n>> active phase (that can be useful for debugging as in \"The phase of\n>> 'Writing objects' takes very long\" -> slow network connection).\n>\n> I like this idea\n>\n>>>> Pushing to github.com:williamdclt/some-repo.git… done\n>>>> 1ca9aaa..4320d30  master -> master\n>>>\n>>>\n>>> I’d be more than happy to work on this (`git push` is an example\n>>> amongst so many other), but want the mailing list’s opinion on it. Am\n>>> I wrong in thinking that this output is not something users want, am I\n>>> fighting windmills or maybe just being ignorant?\n>>\n>> I think this would be a useful patch, but it could get complicated\n>> quickly: push uses other low level git commands to prepare the\n>> packfile to be sent to the server, currently it only needs to pipe\n>> through the output of the low level command (or even have the\n>> low level command directly write to the terminal).\n>>\n>> The output of those low level commands should not be changed\n>> when run on their own, I would assume.\n>\n> Agreed. I didn’t expect it to be so subtle, but I’ll look into it\n> and see if that’s something within my reach.\n\nIt's not *quite* the same topic, but a related WIP patch that got\ndropped (and it would be great if someone looking at this area could\npick it up) is\nhttps://public-inbox.org/git/20180902085503.GA25391@sigill.intra.peff.net/\n\nI think it's also worth looking into making the progress code able to\nemit stuff like:\n\n    Counting / Compressing / Writing objects A% (X_1/Y_2) B% (X_2/Y_2) C% (X_3/Y_3)\n\nThat would allow for splitting up some of these cases where our progress\nbars are overly verbose across multiple lines without losing info by\ncompletely erasing the line, and would also support other cases where\nsometimes we do this stuff concurrently. See e.g. my recent commit-graph\nprogress patches for something that would benefit from this type of\nthing.\n\nIt would need a patch to the progress code to make it able to juggle N\nnumber of progress bars with some format to stitch them all together.\n"},{"id":"364193","messageId":"xmqq36rlsofp.fsf@gitster-ct.c.googlers.com","threadId":"49902","inReplyTo":"758FA299-0842-4462-8CF6-D7210D26A6C7@gmail.com","subject":"Re: Git pull confusing output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-11-28T06:31:38Z","receivedAt":"2018-11-28T06:31:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Will <william.duclot@gmail.com> writes:\n\n> I’m far from being a guru, but I consider myself a competent Git\n> user. Yet, here’s my understanding of the output of one the most-used\n> commands, `git push`:\n>> Counting objects: 6, done.\n> No idea what an “object” is. Apparently there’s 6 of them\n> here. What does “counting” them means? Should I care?\n\nYou vaguely recall that the last time you pushed you saw ~400\nobjects counted there, so you get the feeling how active you were\nsince then.\n\nIt is up to you if you are interested in such a feel of the level of\nactivity.  \"git fetch\" (hence \"git pull\") would also give you a\nsimilar \"feel\", e.g. \"the last fetch was ~1200 objects and today's\nis mere ~200, so it seems it is a relatively slow day\".\n\nAs to \"what is an object?\", there are plenty of Git tutorials and\nbooks to learn the basics from.  Again, it is up to you if you care.\n\n>> Delta compression using up to 4 threads.\n> No idea what is “delta compression”, I suppose something is being\n> compressed. It’s using anything between 1 and 4 threads, which is not\n> a very precise or useful information. Should I care?\n\nLikewise.\n\n>> Compressing objects: 100% (6/6), done.\n> I still don’t know what objects are, but I appreciate having feedback\n> on progress\n\nExactly.\n\n>> Writing objects: 100% (6/6), 656 bytes | 656.00 KiB/s, done.\n> Writing what, where? Should I care? Still good to have feedback\n\nYou are pushing the data in commits you wrote, modifications you\nmade to files, etc., to the other side, so that is what is written\nto the other side.  Is there any other thing you might suspect that\nis written in this context, to make you think a clarification is\nneeded in the above message?\n\n>> Total 6 (delta 4), reused 0 (delta 0)\n> No idea what any of those numbers mean. Should I care?\n\nIt is up to you to get interested in these details and learn what\nthey mean.  In this case, among these 6 objects transferred, Git\nmanaged to find that 4 are similar to other objects the other side\nalready has or being sent by this push and can be transferred very\nefficiently by sending only the difference, which is what \"delta\"\nmeans.\n\n>> remote: Resolving deltas: 100% (4/4), completed with 4 local objects.\n> I do know what’s a remote, but I don’t know what “resolving\n> deltas” means. There’s local objects now? I don’t understand what\n> happened to those local objects, are they the byproduct of the delta\n> resolving or the input or something else? Should I care?\n\nThe \"remote:\" prefix is \"the other side said the following\".  IOW,\nyou are seeing the message from the receiving end.  As you sent 4\nobjects as mere \"difference\" (not the whole data needed to know\nevery byte of the file or directory), the receiving side needed to\nfind the object the \"difference\" was relative to, and reassemble\nwhat you would have sent if there weren't delta compression.  These\n4 local objects were local from the point of view of the other side,\ni.e. the repository that received your push.\n\nThe information density of this one is much lower than the previous\nprogress output lines.  This one is primarily to give you the feeling \nof relative speed (you've seen how fast the \"writing\" phase which is\nconstrained mostly by over-the-wire speed already, and now you are\nobserving how many more seconds are spent to post-process the data\nsent over the wire) and avoiding to get you bored.\n\nI think we have \"--quiet\" option for those who do not care.\n"},{"id":"364248","messageId":"CAGZ79kbORHfkZOYXrCrHgKX_66M8=3jppn9_SU5fuB6_CfAMag@mail.gmail.com","threadId":"49902","inReplyTo":"xmqq36rlsofp.fsf@gitster-ct.c.googlers.com","subject":"Re: Git pull confusing output","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-11-28T20:27:33Z","receivedAt":"2018-11-28T20:27:47Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Nov 27, 2018 at 10:31 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Will <william.duclot@gmail.com> writes:\n>\n> > I’m far from being a guru, but I consider myself a competent Git\n> > user. Yet, here’s my understanding of the output of one the most-used\n> > commands, `git push`:\n> >> Counting objects: 6, done.\n> > No idea what an “object” is. Apparently there’s 6 of them\n> > here. What does “counting” them means? Should I care?\n>\n> You vaguely recall that the last time you pushed you saw ~400\n> objects counted there, so you get the feeling how active you were\n> since then.\n>\n> It is up to you if you are interested in such a feel of the level of\n> activity.  \"git fetch\" (hence \"git pull\") would also give you a\n> similar \"feel\", e.g. \"the last fetch was ~1200 objects and today's\n> is mere ~200, so it seems it is a relatively slow day\".\n>\n> As to \"what is an object?\", there are plenty of Git tutorials and\n> books to learn the basics from.  Again, it is up to you if you care.\n\nWhile this is very interesting to the experienced git user, the\napproximation of activity by object count is very coarse to say at least.\n\nAs It approximates changes in the DAG object count and nothing\nabout the deltas (which as we learn comes later and it comes with\na progress meter in bytes), it only provides the basics.\n\n>\n> I think we have \"--quiet\" option for those who do not care.\n\nI think some users are not focused as much on the version control as\nmuch as they are focused on another problem that is solved with\nthe content inside the repo.\n\nWhich means they only care about 'actionable' output, such as\n* errors\n* information provided by remote\n  (e.g. links to click to start a code review)\n* too long waiting time\n  (so they can abort and inspect the problem)\n\nI would suggest we come up with a mode that is \"not quiet\", but\ncuts down to only the basic actionable items [and make that\nthe default eventually].\n\nNow these actionable items depend on the workflow used,\nfor which I think an email based maintainers workflow is not\nthe norm. The vast majority of people uses git-push to\nupload their change to a code review system instead.\nAnd for such a workflow the size (as proxied by\nobject/delta count) is not as important as the target ref\nthat you push to or potentially the diffstat output of\na potential merge to a target branch.\n\nTLDR: I still think making git-push a bit more quiet is\nbeneficial to the user base at large.\n\nStefan\n"}]}