Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Mon, Oct 24, 2016 at 06:09:00PM -0700, Junio C Hamano wrote:
>
>>  - lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto
>>    scaling the default abbreviation length when Git produces a short
>>    object name to adjust to the modern times.  Peff noticed one
>>    fallout from it recently and its fix jc/abbrev-auto is not yet in
>>    'next'.  I would not be surprised if there are other uncovered
>>    fallouts remaining in the code, but at the same time, I expect
>>    they are all cosmetic kind that do not affect correctness, so I
>>    am inclined to include all of them in the upcoming release.
>
> Yeah, I'd agree any fallouts are likely to be purely cosmetic (and if
> there _is_ some script broken by this, it was an accident waiting to
> happen as soon as it was used in a repo with a partial hash collision).
>
> I'm still not sure if people will balk just at the increased length in
> all of their output. I think I'm finally starting to get used to it. :)

I am finally getting used to it.  At this point, I think the
transition plan would be to tell them to set core.abbrev to
whatever default they like.

>> * jc/abbrev-auto (2016-10-22) 4 commits
>>  - transport: compute summary-width dynamically
>>  - transport: allow summary-width to be computed dynamically
>>  - fetch: pass summary_width down the callchain
>>  - transport: pass summary_width down the callchain
>>  (this branch uses jk/abbrev-auto and lt/abbrev-auto.)
>> 
>>  "git push" and "git fetch" reports from what old object to what new
>>  object each ref was updated, using abbreviated refnames, and they
>>  attempt to align the columns for this and other pieces of
>>  information.  The way these codepaths compute how many display
>>  columns to allocate for the object names portion of this output has
>>  been updated to match the recent "auto scale the default
>>  abbreviation length" change.
>> 
>>  Will merge to 'next'.
>
> In case it was not obvious, I think this topic is good-to-go. And
> clearly any decision on lt/abbrev-auto should apply to this one, too. I
> notice you built it on jk/abbrev-auto, though, which is listed as
> "undecided". That's fine by me, but I think it would technically hold
> this topic hostage. You might want to adjust that before merging to
> next.

I am planning to merge both lt/* and jk/*; I should have said it
more clearly.

Thanks.