Jeff King writes:
> I started on this, and it turned out not to really be any simpler
> So I went ahead with the full formats for my re-roll. It turned out
> pretty reasonable, I think.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
On Mon, Jul 08, 2013 at 07:07:01PM +0530, Ramkumar Ramachandra wrote:
> > There's also syntax sharing. I don't think each command should have
> > its own syntax. f-e-r already has %(objectsize). If we plan to have a
> > common syntax, perhaps %(disk-size) should be %(objectsize:disk) or
> > someth
On Sun, Jul 07, 2013 at 10:49:46AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Perhaps we need
> >
> > git cat-file --batch-format="%(disk-size) %(object)"
> >
> > or similar.
>
> I agree with your reasoning. It may be simpler to give an interface
> to ask for which pieces of info
On Sun, Jul 07, 2013 at 09:15:41PM +, brian m. carlson wrote:
> On Sun, Jul 07, 2013 at 06:09:49AM -0400, Jeff King wrote:
> > +NOTE: The on-disk size reported is accurate, but care should be taken in
> > +drawing conclusions about which refs or objects are responsible for disk
> > +usage. The
Duy Nguyen wrote:
> - We might overlook something. The best way to avoid missing is
> finish and verify it.
> - A promise to do things later could happen really late, or never
> happens. As you are sastisfied with the functionality you have less
> motivation to clean the code. Meanwhile the maint
On Mon, Jul 8, 2013 at 8:37 PM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>> The short/long naming is the least I worry about. We could add long
>> names to pretty specifiers. The thing about the last attempt is, you
>> add some extra things on top elsewhere, but format_commit_item code
>> m
Duy Nguyen writes:
> There's also syntax sharing. I don't think each command should have
> its own syntax. f-e-r already has %(objectsize). If we plan to have a
> common syntax, perhaps %(disk-size) should be %(objectsize:disk) or
> something. Adding formatting to cat-file --batch from scratch co
Duy Nguyen wrote:
> The short/long naming is the least I worry about. We could add long
> names to pretty specifiers. The thing about the last attempt is, you
> add some extra things on top elsewhere, but format_commit_item code
> may need to be aware of those changes, which are not obvious when
>
On Mon, Jul 8, 2013 at 7:00 PM, Ramkumar Ramachandra wrote:
>> This is what I wanted to do with the in for-each-ref's pretty
>> formatting [1]. I used to hack cat-file --batch to extract info I
>> needed for experimenting with various pack index extensions. If you
>> are not in hurry, maybe we can
Duy Nguyen wrote:
> Ram, are you still interested in the awesome branch series?
Yep, but it got stalled due to lack of reviewer-interest :/
I'm a bit under the weather at the moment, but it's good to see that
you're back: let's finish this soon.
>>> Perhaps we need
>>>
>>> git cat-file --batch
un Mon, Jul 8, 2013 at 12:49 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Perhaps we need
>>
>> git cat-file --batch-format="%(disk-size) %(object)"
>>
>> or similar.
This is what I wanted to do with the in for-each-ref's pretty
formatting [1]. I used to hack cat-file --batch to extract
On Sun, Jul 07, 2013 at 06:09:49AM -0400, Jeff King wrote:
> +NOTE: The on-disk size reported is accurate, but care should be taken in
> +drawing conclusions about which refs or objects are responsible for disk
> +usage. The size of a packed non-delta object be much larger than the
You probably me
On Sun, Jul 07, 2013 at 10:49:46AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Perhaps we need
> >
> > git cat-file --batch-format="%(disk-size) %(object)"
> >
> > or similar.
>
> I agree with your reasoning. It may be simpler to give an interface
> to ask for which pieces of info
Jeff King writes:
> Perhaps we need
>
> git cat-file --batch-format="%(disk-size) %(object)"
>
> or similar.
I agree with your reasoning. It may be simpler to give an interface
to ask for which pieces of info, e.g. --batch-cols=size,disksize,
without giving the readers a flexible "format".
>
This option is just like --batch-check, but shows the
on-disk size rather than the true object size. In other
words, it makes the "disk_size" query of sha1_object_info_extended
available via the command-line.
This can be used for rough attribution of disk usage to
particular refs, though see the c
15 matches
Mail list logo
