On Tue, Nov 27, 2018 at 8:52 AM Will <william.duc...@gmail.com> wrote:
> And even them, do they need this info every time they push? I agree that we should make the output a bit more user friendly, which means we'd only want to output relevant data for the user. The different phases taking each one line takes up precious screen real estate, so another approach would be delete the line after one phase is finished, such that you'd only see the currently active phase (that can be useful for debugging as in "The phase of 'Writing objects' takes very long" -> slow network connection). > I feel like a less intimidating output would help, while showing info > about objects and deltas with the verbose flag: I agree that most information in pushing is not very useful and could be omitted. This helps in multiple ways: * it keeps the focus on the actually important information, see bf1a11f0a1 (sideband: highlight keywords in remote sideband output, 2018-08-07) * less space in a terminal wasted, such that you can scroll over it better > > Compressing… done After the push succeeded this information would not be useful any more, it is only useful during the compression phase (Does it progress quickly enough? or does it error out?) Slightly related (but applies mostly to fetch, for which this discussion can also be had): When fetching, these informations are generated on the remote side (as the server needs to create the packfile according to your local state that you negotiated with the server), which takes some time. Sending over this information also keeps the connection alive. This is only relevant in corner cases depending on the setup of the hosting provider/repository, but it led to commits such as https://eclipse.googlesource.com/jgit/jgit/+/a38531b21c7e2b0dc956e0ed1bfc9513f604273c in the java implementation of Git. > > Pushing to github.com:williamdclt/some-repo.git… done > > 1ca9aaa..4320d30 master -> master > > > I’d be more than happy to work on this (`git push` is an example > amongst so many other), but want the mailing list’s opinion on it. Am > I wrong in thinking that this output is not something users want, am I > fighting windmills or maybe just being ignorant? I think this would be a useful patch, but it could get complicated quickly: push uses other low level git commands to prepare the packfile to be sent to the server, currently it only needs to pipe through the output of the low level command (or even have the low level command directly write to the terminal). The output of those low level commands should not be changed when run on their own, I would assume. So maybe the best way to dive into understanding what happens under the hood in git-push is to run GIT_TRACE=1 git push ... and see what child processes are invoked (e.g. run_command: git pack-objects --all-progress-implied) and then we'd need to change the output of iff the specific progress flag is given. Stefan
