git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jakub Narebski <jnareb@gmail.com>
Date
May 15, 2007, 23:19 UTC
Message-ID
<200705160119.10802.jnareb@gmail.com>
In-Reply-To
<7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 8 quoted lines
> 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...
> * 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.

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

But certainly padding is not needed.
Show 5 quoted lines
> * Does it make sense to show size information when giving a tree
>   entry?  I realize not having it in the output would make the
>   job of the script reading the output a bit harder, but if this
>   output is meant also for human consumption I think it would
>   not be so interesting and raise a confusion factor.

Giving tree size information is similar to 'ls -l giving size of directory, and not total size taken by its contents. That would be better left for git-ls-tree `--du' option :-)

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

-- 
Jakub Narebski
Poland
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 9 in “Add an option to git-ls-tree to display also the size of object”
  1. Add an option to git-ls-tree to display also the size of objectJakub Narebski, May 15, 2007
  2. Junio C HamanoMay 15, 2007
  3. Jakub NarebskiMay 15, 2007
  4. Junio C HamanoMay 16, 2007
  5. Jakub NarebskiMay 16, 2007
  6. Junio C HamanoMay 16, 2007
  7. Add an option to git-ls-tree to display also the size of blobJakub Narebski, May 19, 2007
  8. Shawn O. PearceMay 20, 2007
  9. Shawn O. PearceMay 15, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.