Re: [BUG] index corruption with git commit -p

From: Jeff King <peff@peff.net>
Date: Sep 2, 2018, 08:02 UTC
Message-ID: <20180902080205.GD18787@sigill.intra.peff.net>
In-Reply-To: <20180902075351.lkfnekklnwot7lzf@ltop.local>

On Sun, Sep 02, 2018 at 09:53:53AM +0200, Luc Van Oostenryck wrote:

Show 16 quoted lines

> > At any rate, I think this perfectly explains the behavior we're seeing.
> 
> Yes, this certainly make sense.
> 
> For fun (and testing) I tried to take the problem in the other direction:
> * why hasn't this be detected earlier (I'm reasonably be sure I did the
>   same operation a few times already without seeing the corruption)?
> * how easy it is to reproduce the problem?
> * Is it enough to do an interactive commit with nothing needing interactive?
> 
> So I tried the following and some variants:
>   > for i in $(seq -w 0 100); do echo $i > f$i; done
>   > git add f* && git commit -m add f* && git rm -q f* && git commit -m rm -p
> 
> but I didn't succeed to recreate the problem. So I'm still wondering
> what is special in my repository & tree that trigger the corruption.

I think the partial deletion is important, because it means that the resulting index is going to be smaller. And the truncation problem only matters when we go from a larger file to a smaller one (since otherwise overwrite the old content completely).

And it doesn't seem to trigger without the interactive "-p". I think that's not directly related, but it somehow triggers the case where we actually need to update the cache tree in this particular order.

That's pretty hand-wavy, but I think it gives a sense of why most people didn't run into this. I do wish I understood better what it would take to create a minimal example for the test suite.

-Peff