On Sun, Sep 02, 2018 at 09:53:53AM +0200, Luc Van Oostenryck wrote: > > 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
