On Sun, Mar 22, 2020 at 09:47:49AM -0600, Taylor Blau wrote: > > > [1] I'm actually not quite sure about correctness here. It should be > > > fine to generate a graph file without any given commit; readers will > > > just have to load that commit the old-fashioned way. But at this > > > phase of "commit-graph write", I think we'll already have done the > > > close_reachable() check. What does it mean to throw away a commit at > > > this stage? If we're the parent of another commit, then it will have > > > trouble referring to us by a uint32_t. Will the actual writing phase > > > barf, or will we generate an invalid graph file? > > > > It doesn't seem great. If I instrument Git like this to simulate an > > object temporarily "missing" (if it were really missing the whole repo > > would be corrupt; we're trying to see what would happen if a race causes > > us to momentarily not see it): > > This is definitely a problem on either side of this patch, which is > demonstrated by the fact that you applied your changes without my patch > on top (and that my patch isn't changing anything substantial in this > area like removing the 'continue' statement). > > Should we address this before moving on with my patch? I think that we > *could*, but I'd rather go forward with what we have for now, since it's > only improving the situation, and not introducing a new bug. I do agree it's a problem before your patch. But I think your patch may make it a lot more common, if only because it means we'd _actually_ be dropping entries for objects that went away, instead of accidentally keeping them due to re-using the graph result. So it probably is worth trying to deal with it now, or at least thinking hard about it. The trouble is that I'm not sure what _should_ happen. Aborting the whole commit-graph generation seems overboard (and would be annoying for cases where whole swaths of history became unreachable and went away; presumably we'd be dropping _all_ of those objects, and the write phase would be just fine). I have a feeling the correct solution is to do this merging pass earlier, before we check close_reachable(). Or if not a true merging pass, at least a pass to check which existing entries are still valid. But I don't know how painful that reordering would be. -Peff
