On Sep 29, 2007, at 2:00 AM, Shawn O. Pearce wrote:
* There's a ton of extraneous output from git-fetch. I would love tosee it reduced to a single-line progress bar, (even if a multiple-staged progress bar). I'm imagining a final line something like: Computing (100%) Transferring (100%) But you can imagine more accurate words than those, (I'm not even sure what all of the things mean that git-fetch is currently reporting progress on).Yea. About half of that output is from pack-objects and either unpack-objects or index-pack. The other part is from git-fetch itself as it updates the local tracking branches (if any are to be updated). Now that git-fetch is in C and reasonably stable maybe I can look into making this prettier. Few people really grok the pack-objects/index-pack output, nor do they care. They just want to know two things: - Is git working or frozen in limbo? - Is git frozen because my network sucks, or git sucks? - When will this be done? Please $DIETY, I want to go home! Make the fetch finish! The C based git-fetch made the http protocol almost totally silent. (No more got/walk messages.) But that's actually also bad as it now doesn't even let you know its transferring anything at all. There are serious issues here about getting the user the progress they really want. The last item ("When will this be done?") is actually not possible to determine under either the native git protocol or HTTP/FTP. We have no idea up front how much data must be transferred. In the native git case we do know how many objects, but we don't know how many bytes that will be. It could be under a kilobyte in one project. That same object count for a different set of objects fetch could be 500M. Radically different transfer times would be required.
Often you know that you have a good connection and you are not interested in any progress reporting at all. _No_ output would be perfect. A return code of 0 would already tell you all you need to know. If you'd like to know more you could pass something like '--verbose' or '--progress'. Quite often git prints a lot of very technical information that is not very interesting as long as things succeed without error. Some examples are - git fetch (see above) - git rebase: prints a lot of details that I'm not interested in unless the rebase fails. - git push: prints updates of remote heads. A message about failing to update a remote head may get lost. - git merge: the fact that a merge is a fast forward merge gets printed at the very top, followed by (often a lot of) diffstat. I know diffstat can help to judge if the merge did what you expected. But even more important is the fact that the merge was just a fast forward, which may get buried under lots of output. Maybe git should become more quiet, as other unix tools are, and per default only report problems. Technical details and progress could be requested explicitly by '--verbose' or similar. We could pipe all the technical output to a per-repository logfile, which can be consulted in case of errors. The log could be cropped during 'git gc'. Steffen - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
