Comment by blt
6 years ago
This is a great resource. I will return to read it closely next time I am designing a CLI.
One thing that puzzled me: `git push` is given as an example of the principle "If you change state, tell the user". Its output is:
$ git push
Enumerating objects: 18, done.
Counting objects: 100% (18/18), done.
Delta compression using up to 8 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 2.09 KiB | 2.09 MiB/s, done.
Total 10 (delta 8), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (8/8), completed with 8 local objects.
To github.com:replicate/replicate.git
+ 6c22c90...a2a5217 bfirsh/fix-delete -> bfirsh/fix-delete
The state change information only comes after many lines of (IMO) unnecessary detail about the inner workings of `git push`. I think this would be much better:
$ git push
Writing objects: 100% (10/10), 2.09 KiB | 2.09 MiB/s, done.
Pushed 10 objects to github.com:replicate/replicate.git
+ 6c22c90...a2a5217 bfirsh/fix-delete -> bfirsh/fix-delete
I think the problem with this approach is when you start to utilise large (normally mono) repos the earlier stages can take significant time.
Then you're in a condumdrum of if you make the loading more generic or have an input lag to get to "writing objects".
You could have temporary progress information that (by default) gets overwritten when in an interactive terminal.