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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 25, 2016, 18:41 UTC
Message-ID: <xmqqy41cqnj3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20161025183057.x24gqm56tgshyuvu@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

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

Show 23 quoted lines

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