From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add an option to git-ls-tree to display also the size of object
Date: Wed, 16 May 2007 01:19:10 +0200 [thread overview]
Message-ID: <200705160119.10802.jnareb@gmail.com> (raw)
In-Reply-To: <7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net>
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...
> * 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.
> * 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
next prev parent reply other threads:[~2007-05-15 23:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 10:24 [PATCH] Add an option to git-ls-tree to display also the size of object Jakub Narebski
2007-05-15 18:58 ` Junio C Hamano
2007-05-15 23:19 ` Jakub Narebski [this message]
2007-05-16 0:37 ` Junio C Hamano
2007-05-16 0:54 ` Jakub Narebski
2007-05-16 1:07 ` Junio C Hamano
2007-05-19 20:08 ` [PATCH v2] Add an option to git-ls-tree to display also the size of blob Jakub Narebski
2007-05-20 3:54 ` Shawn O. Pearce
2007-05-15 23:20 ` [PATCH] Add an option to git-ls-tree to display also the size of object Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705160119.10802.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.