On Wed, Aug 8, 2018 at 8:39 PM Junio C Hamano wrote:
> One more, and hopefully the final, note.
>
> ..
Much appreciated. I don't think I could figure all this out no matter
how long I stare at those commits and current code.
--
Duy
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> not used behind is *not* OK. And lack of restoring the bottom in
>> the new codepath makes me suspect exactly such a bug _after_ the
>> traversal exits the subtree we are using this new optimization in
>> and moves on.
>
> Hmph, thinking
Junio C Hamano writes:
> not used behind is *not* OK. And lack of restoring the bottom in
> the new codepath makes me suspect exactly such a bug _after_ the
> traversal exits the subtree we are using this new optimization in
> and moves on.
Hmph, thinking about this further, I cannot convince
Duy Nguyen writes:
> On Mon, Aug 6, 2018 at 5:48 PM Junio C Hamano wrote:
>> > I've also checked about the lookahead thing in unpack_trees() to see
>> > if we accidentally break something there, which is my biggest worry.
>> > See [1] and [2] for context, but I believe since we can't have D/F
On 8/6/2018 2:59 PM, Junio C Hamano wrote:
Duy Nguyen writes:
We require the unpacked entry from all input trees to be a tree
objects (the dirmask thing), so if one tree has 't' as a file,
Ah, OK, this is still part of that "all the trees match cache tree
so we walk the index instead"
Duy Nguyen writes:
> We require the unpacked entry from all input trees to be a tree
> objects (the dirmask thing), so if one tree has 't' as a file,
Ah, OK, this is still part of that "all the trees match cache tree
so we walk the index instead" optimization. I forgot about that.
On Mon, Aug 6, 2018 at 5:48 PM Junio C Hamano wrote:
> > I've also checked about the lookahead thing in unpack_trees() to see
> > if we accidentally break something there, which is my biggest worry.
> > See [1] and [2] for context, but I believe since we can't have D/F
> > conflicts, the
Nguyễn Thái Ngọc Duy writes:
> This is a minor update to address Ben's comments and add his
> measurements in the commit message of 2/4 for the record.
Yay.
> I've also checked about the lookahead thing in unpack_trees() to see
> if we accidentally break something there, which is my biggest
This is a minor update to address Ben's comments and add his
measurements in the commit message of 2/4 for the record.
I've also checked about the lookahead thing in unpack_trees() to see
if we accidentally break something there, which is my biggest worry.
See [1] and [2] for context, but I
9 matches
Mail list logo
