Jakub Narebski <jnareb@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Jakub Narebski <jnareb@xxxxxxxxx> 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 ;-) >> * 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. >> * 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. >> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
