Jeff King <peff@xxxxxxxx> 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.