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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox