On Thu, Oct 17, 2019 at 04:03:00PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Hmm, I am kind of surprised that the decoding side allowed such a
> >> padding.
> >
> > IIRC, the "padding" is just a sequence of 0-length-plus-continuation-bit
> > varint bytes. And for some reason it wor
Jeff King writes:
>> Hmm, I am kind of surprised that the decoding side allowed such a
>> padding.
>
> IIRC, the "padding" is just a sequence of 0-length-plus-continuation-bit
> varint bytes. And for some reason it worked for the size but not for the
> delta offset value.
I think the reason is b
On Sat, Oct 12, 2019 at 09:04:58AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The current code does so by creating a new entry in the reused_chunks
> > array. In the worst case that can grow to have the same number of
> > entries as we have objects. So this code was an attempt to pad
Jeff King writes:
> The current code does so by creating a new entry in the reused_chunks
> array. In the worst case that can grow to have the same number of
> entries as we have objects. So this code was an attempt to pad the
> header of a shrunken entry to keep it the same size. I don't remembe
> > This makes sense - offsets may be different when we omit objects from
> > the packfile. I think this can be computed by calculating the number of
> > zero bits between the current object's index and the nth object prior
> > (where n is the offset) in the bitmap resulting from
> > reuse_partial_
On Thu, Oct 10, 2019 at 04:59:52PM -0700, Jonathan Tan wrote:
> > +/*
> > + * Record the offsets needed in our reused packfile chunks due to
> > + * "gaps" where we omitted some objects.
> > + */
> > +static struct reused_chunk {
> > + off_t start;
> > + off_t offset;
> > +} *reused_chunks;
>
On Fri, Oct 11, 2019 at 1:59 AM Jonathan Tan wrote:
>
> I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
>
> > int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> > struct packed_git **packfile,
> > -
I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
> int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> struct packed_git **packfile,
> -uint32_t *entries, off_t *up_to);
> +
On Thu, Oct 3, 2019 at 4:06 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > Hmm, I see the early parts of this graduated to 'next'. I'm not sure
> > everything there is completely correct, though. E.g. I'm not sure of the
> > reasoning in df75281e78 (ewah/bitmap: always allocate 2 more words
Jeff King writes:
> Hmm, I see the early parts of this graduated to 'next'. I'm not sure
> everything there is completely correct, though. E.g. I'm not sure of the
> reasoning in df75281e78 (ewah/bitmap: always allocate 2 more words,
> 2019-09-13).
> ...
> I'm sorry for being so slow on giving it
On Fri, Sep 13, 2019 at 08:06:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Sep 13, 2019 at 03:29:00PM -0700, Junio C Hamano wrote:
> >
> >> This comment has nothing to do with the change, but the way the
> >> patch is presented is quite hard to follow, in that the preimage
Jeff King writes:
> On Fri, Sep 13, 2019 at 03:29:00PM -0700, Junio C Hamano wrote:
>
>> This comment has nothing to do with the change, but the way the
>> patch is presented is quite hard to follow, in that the preimage or
>> the common context lines do not help understand what the new code is
>
On Fri, Sep 13, 2019 at 03:29:00PM -0700, Junio C Hamano wrote:
> This comment has nothing to do with the change, but the way the
> patch is presented is quite hard to follow, in that the preimage or
> the common context lines do not help understand what the new code is
> doing at all ;-)
>
> I'l
Christian Couder writes:
> +/*
> + * Record the offsets needed in our reused packfile chunks due to
> + * "gaps" where we omitted some objects.
> + */
The meaning of 'start' and 'offset' is unclear from the first
reading. Is it "starting offset" and "for how many bytes the region
lasts"? If so
14 matches
Mail list logo
