Jeff King <peff@xxxxxxxx> writes: > Do we want to do anything with the other dependency hole I found here: > > http://article.gmane.org/gmane.comp.version-control.git/215211 > > It's definitely a potential problem, but I don't think we have any > reports of it happening in practice, so it might not be worth worrying > about. Doing a clean version of the fix here: > > http://article.gmane.org/gmane.comp.version-control.git/215212 > > would probably involve reorganizing our .depend directory structure, > unless somebody can cook up some clever use of make's patsubst. As I understand how the current set-up works: * Initially, we do not have foo.o but foo.c. We automatically build foo.o because it depends on foo.c via the "%.o : %.c" rule, and as a side effect, we also build .depend/foo.o.d file; * Then, if any real dependency used to build the existing foo.o that is recorded in .depend/foo.o.d file changes, foo.o gets rebuilt, which would update .depend/foo.o.d again for the next invocation. The case where you lose .depend/foo.o.d is a special case of getting a wrong information in .depend/foo.o.d, which may happen by using a broken compiler during the initial build, or going over quota and getting .depend/foo.o.d truncated, or by other breakages. The user may have done "rm -rf .depend" to lose it, or the user may have done something like this to munge it: find -name '.git' -type d -prune -o -print0 | xargs -0 sed -i -e 's/foo/bar/g' forgetting that just like .git, .depend is precious and should not be touched. I think this really boils down to where we draw the "this is good enough" line. I am not sure if losing the file as in $gmane/215211 is common enough to be special cased to buy us much, while leaving other ".depend/foo.o.d was updated to contain a wrong info" cases still broken. And of course the case where .depend/foo.o.d is munged by mistake cannot be solved without recompiling everything all the time, so... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html