On Tue, Sep 04, 2018 at 07:36:43PM -0400, Jeff King wrote: > On Tue, Sep 04, 2018 at 12:38:07PM -0400, Jeff King wrote: > > > > And just to be clear I'm looking forward to a patch from Jeff to fix > > > this since he clearly put more thoughts on this than me. With commit.c > > > being the only user of reopen_lock_file() I guess it's even ok to just > > > stick O_TRUNC in there and worry about O_APPEND when a new caller > > > needs that. > > > > That's the way I'm leaning to. The fix is obviously a one-liner, but I > > was hoping to construct a minimal test case. I just haven't gotten > > around to it yet. > > It turned out not to be too bad to write a test. It feels a little like > black magic, since I empirically determined a way in which the > cache-tree happens to shrink with the current code. But that assumption > is tested with a sanity check, so we'll at least know if it becomes a > noop. > > > The bug is ancient, so I don't think it's important for v2.19. > > The patch below should work on master or maint. We could do a fix > directly on top of the bug, but merging-up is weird (because the buggy > code became part of a reusable module). It's great that you were able to create a reproducer relatively easily. Thank you, guys. -- Luc
