Re: Segmentation fault with latest git (070c57df)

Jeff King [off-list ref] writes:

On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:

quoted

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.

Hmm. Yeah, I was thinking it might be more common than ordinary munging
due to something like an interrupted "git clean -x". But given that:

  1. As far as I can tell, it is not a situation that can happen through
     regular use of checkout/make/etc, and...

  2. We have zero reports of it happening in practice (I only discovered
     it while explicitly trying to break the Makefile), and...

  3. It is just one of many possible breakages, all of which can be
     fixed by "git clean -dx" if you suspect issues...

let's just leave it. Thanks for a sanity check.

The only case that worries me is when make or cc gets interrupted.
As long as make removes the ultimate target *.o in such a case, it
is fine to leave a half-written .depend/foo.o.d (or getting it
removed) behind.

How expensive to generate the dependency for a single foo.c file
into a temporary without compiling it into foo.o, and comparing the
resulting dependency with existing .depend/foo.o.d?  If it is very
cheap, it might be worth doing it before linking the final build
product and error the build out when we see discrepancies.  I dunno.