Re: [RFC/PATCH] core.abbrev doc: document and test the abbreviation length

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 06 2019, Jeff King wrote:

> On Tue, Feb 05, 2019 at 12:50:23AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> >> As this is pretty-much a test-only option, perhaps going longer but
>> >> more descriptive would make sense?
>> >>
>> >> 	git rev-parse --compute-abbrev-length-for <object-count>
>> >>
>> >> may be an overkill, but something along those lines.
>> >
>> > You could even default <object-count> to the number of objects in the
>> > repository. Which implies that perhaps the best spot is the command
>> > where we already count the number of objects, git-count-objects.
>>
>> That's documented as reporting loose objects by default, although it has
>> a full report with -v.
>
> True, though I think that's mostly for historical reasons. It _could_ be
> part of the full report, like:
>
>   $ git count-objects -v
>   ...
>   abbrev-len: 12
>
> but from your test-script usage, I'd expect you'd want to be able to
> feed a fake count to it, like:
>
>   git count-objects --compute-abbrev-len=1234

Yeah for just reporting it count-objects makes more sense. I think I'll
add it there...

> or something (of course you _could_ also make a repository with N
> objects, but that's a lot more expensive).

...but yes, for the test script & to export the info I'd like to have
the "what's the abbrev length for a repo with N objects" option, which
would be for rev-parse.

>> Maybe rev-parse isn't the right place, I just picked it because it seems
>> to be the general utility belt for stuff that doesn't fit elsewhere.
>>
>> But putting it in git-count-objects seems like a bit more of a stretch
>> given the above.
>
> I dunno. It seems like less of a stretch to me, but it is true that
> rev-parse is already a kitchen sink repository. I can live with it
> either way.
>
> -Peff




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux