Should we use that opportunity to implement an option like -h (for
humanize) similar to what ls(1), df(1), du(1) does ? Of course "-h" is
already used for help, so we could use -H or any other sensible
It can become tough to read the size when it gets big enough.

On Thu, Apr 4, 2013 at 6:27 PM, Junio C Hamano <> wrote:
> Mihai Capotă <> writes:
>> The git manual contains an explicit warning about the output of a
>> porcelain command changing: "The interface to Porcelain commands on
>> the other hand are subject to change in order to improve the end user
>> experience."
> Yeah, I know that, as I wrote it ;-)
> Aside from count-object being not exactly a Porcelain, the statement
> does not give us a blank check to make random changes as we see fit.
> There needs to be a clear improvement.
> I am just having a hard time weighing the benefit of using more
> accurate kibibytes over kilobytes and the possible downside of
> breaking other peoples' tools.
> Perhaps it would be alright if the change was accompanied by a
> warning in the Release Notes to say something like:
>         If you have scripts that decide when to run "git repack" by
>         parsing the output from "git count-objects", this release
>         may break them.  Sorry about that.  One of the scripts
>         shipped by git-core itself also had to be adjusted.  The
>         command reports the total diskspace used to store loose
>         objects in kibibytes, but it was labelled as "kilobytes".
>         The number now is shown with "KiB", e.g. "6750 objects,
>         50928 KiB".
>         You may want to consider updating such scripts to always
>         call "git gc --auto" to let it decide when to repack for
>         you.
> Also, I suspect that for the purpose of this exact output field,
> nobody cares the difference between kibibytes and kilobytes.
> Depending on the system, we add up either st.st_blocks or st.st_size
> and the result is not that exact as "how much diskspace is
> consumed".
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to
> More majordomo info at
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to