Branko Čibej wrote on Mon, 26 Nov 2018 05:38 +0100:
> I really like the idea of 'svn ls -vH' as a sort of mnemonic of 'ls -lh'.
> Note that whilst the actual option letters are different -- on
> purpose, we had a long discussion about -v vs. -l a long time ago -- the
> use of single-letter options in this case would be nice. I suspect -H
> would be used almost as often as -v, but no-one would probably bother
> with --human-readable. (OK, bash-completion helps.)
I don't run 'svn ls' often.
> >> I'd though about adding a --base-10 flag, so '-H' is base-2 units and
> >> '-H --base-10' would use base-10 units. I do think that the default
> >> should be base-2, because users are probably more used to thinking that
> >> way. Well, at least programmers are, and they are, after all, the main
> >> users of version control.
> > I'm not a fan of having one flag modify another flag's meaning. I'd prefer
> >
> > --base=2
> > --base=10
>
> Not so bad. I'd call it --unit-base then, to avoid confusion with number
> bases.
>
> > (we needn't support other values (except perhaps --base=1 for the 1.11 behaviour))
>
> ?:\ Which behaviour?
The default behaviour: printing the filesize as an integer (possibly with
thousands separator). Mathematically, base-2 means the printed value N
stands for N * 2**foo, so the 1.11 behaviour is equivalent to --unit-base=1.
It might be clearer to just call it --unit-base=none.
> > I suppose we could then have --human-readable as "currently, an alias to
> > --base=10", with an option to extend it --- like 'diff --patch-compatible'.
>
> I like this approach. But I'd make --human-readable === --unit-base=2,
> for reasons already mentioned.
Sorry, yes. In context of filesizes base-2 as default makes sense.
>
Received on 2018-11-26 05:58:32 CET