On Thu, Apr 4, 2013 at 6:27 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Mihai Capotă <mi...@mihaic.ro> 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
> 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
> 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
I agree completely. I think the release notes warning is a good plan.
Just in case you decide against it, I'm also sending a completely
different patch to document the issue.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html