Re: [PATCH] Add an option to git-ls-tree to display also the size of object

From: Junio C Hamano <junkio@cox.net>
Date: May 16, 2007, 00:37 UTC
Message-ID: <7vps51hacw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200705160119.10802.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 11 quoted lines

> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> 
>> > Add -l/--long/--size option to git-ls-tree command, which displays
>> > object size of an entry after object id (left-justified with minimum
>> > width of 7 characters).
>> 
>> Not a NAK at all (but not an ACK either yet), but just asking
>> questions on some design considerations.
>
> I guess I should use [PATCH/RFC] for this patch...

I do not see any need for that. As far as I am concerned, all the [PATCH] are RFCs ;-)

Show 6 quoted lines

>> * Do these options do different things?  If not, why have more
>>   than one (or two, --long and its shorthand -l)?
>
> The idea was to have output similar (if possible by git-ls-tree
> machinery) to 'ls -l' output, hence -l/--long, but actually it is
> about --size.

"ls -l" is about long (it is not "long to show everything the system knows", but "longer than usual), so I think it is Ok to say "ls-tree -l" and people would understand.

Show 6 quoted lines

>> * Why pad to 7 places?  Do we have a similar padding elsewhere?
>>   Will this ever used by non-scripts?  How does this padding
>>   affect parsers other than Perl that read this information?
>
> Padding is added here to make output more human-readable. And I guess
> padding of 7 places is default for 'ls -l'.

Ok, "it is to make the output also consumable more easily by humans" is a very reasonable answer.

Show 8 quoted lines

>>   Also I suspect that having to show the size of a tree object,
>>   expressed in terms of the canonical representation, might
>>   force packv4 aware ls-tree to convert its traversal efficient
>>   representation to the canonical one only to get its size.
>
> It still will be accessible, but perhaps it would be less efficient
> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O) 
> time...

Shawn answered this better than I could. I am moderately negative on the size of tree objects part.

But modulo these details, I agree that being able to get the size of each blob would be useful.