Re: [WIP v2 0/2] Modifying pack objects to support --blob-max-bytes

2017-06-07 Thread Jeff King
On Mon, Jun 05, 2017 at 10:35:23AM -0700, Jonathan Tan wrote: > > The rest of the pack code uses a varint encoding which is generally > > much smaller than a uint64 for most files, but can handle arbitrary > > sizes. > > > > The one thing it loses is that you wouldn't have a fixed-size record, so

Re: [WIP v2 0/2] Modifying pack objects to support --blob-max-bytes

2017-06-05 Thread Jonathan Tan
Thanks for your comments. On Fri, 2 Jun 2017 18:16:45 -0400 Jeff King wrote: > On Fri, Jun 02, 2017 at 12:38:43PM -0700, Jonathan Tan wrote: > > > > Do we need to future-proof the output format so that we can later > > > use 32-byte hash? The input to pack-objects (i.e. rev-list --objects) > >

Re: [WIP v2 0/2] Modifying pack objects to support --blob-max-bytes

2017-06-02 Thread Jeff King
On Fri, Jun 02, 2017 at 12:38:43PM -0700, Jonathan Tan wrote: > > Do we need to future-proof the output format so that we can later > > use 32-byte hash? The input to pack-objects (i.e. rev-list --objects) > > is hexadecimal text, and it may not be so bad to make this also > > text, e.g. " SP LF

[WIP v2 0/2] Modifying pack objects to support --blob-max-bytes

2017-06-02 Thread Jonathan Tan
Here's a new version addressing Junio's comments. > Hmph, that statement is a hard to read and agree to. I thought an > ignored object that is not going to be packed is one that won't hit > to_pack? That is true currently, but will not be the full truth once the 2nd patch is applied. I have exp