Jeff King <> writes:

> Do we want to do anything with the other dependency hole I found here:
> 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:
> 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

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
More majordomo info at

Reply via email to