CLI Guidelines – A guide to help you write better command-line programs

Re:CLI Guidelines – A guide to help you write better command... by blt on Saturday December 05, 2020 @01:49AM (#25312414)

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

[ Parent | on HN ]

Re:CLI Guidelines – A guide to help you write better command... by djrhails on Saturday December 05, 2020 @06:56AM (#25313894)

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".

[ Parent | on HN ]

Re:CLI Guidelines – A guide to help you write better command... by account42 on Monday December 07, 2020 @07:05AM (#25331365)

You could have temporary progress information that (by default) gets overwritten when in an interactive terminal.

[ Parent | on HN ]