Jeff King <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
