On Sun, Jan 26, 2020 at 6:09 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 1/25/2020 3:59 PM, Elijah Newren wrote: > > On Fri, Jan 24, 2020 at 7:41 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > >> I'm CC'ing Elijah because he also made changes to dir.c, and > >> perhaps he has some idea of what's going on. > > > > If you think it might be related to the dir.c changes, I can take a > > look. I don't have any immediate ideas off the top of my head. > > The only thing I can think of is that these paths are already > marked as sparse, but something is requiring us to test if the > path can be created with the filesystem. I'll try to debug > more into exactly where that is. It's telling that this happens > both in cone mode and without. Yeah, I'll take a look. The exponentially slow 'status --ignored' report is forcing me to look at dir.c again anyway, though it's also delaying me from getting a chance to look at this particular report. > > However, since I'm really suffering with "git read-tree -mu HEAD" > > being the mechanism for updating sparsity (for reasons independent of > > the issue being discussed here), I've been tempted to dig into that > > anyway to write a replacement without the nasty side-effects. I'll > > take a look early next week and see if I can spot anything. > > If by "nasty side-effects" you mean "overwrites staged changes, even > if in the sparse set before and after" then I would welcome such a > change. Otherwise, it will fall to me, and this is far outside of > my expertise. Of course, it is something I should learn, but I can > learn that during code review, too. ;) Yep, that's exactly what I mean. It'd be nice if Duy were still around to bug, but I've touched unpack-trees a few times so I might be able to find my way around. I'll try to take a stab at it. > Thanks, > -Stolee
