Re: Segmentation fault with latest git (070c57df)

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2013, 09:29 UTC
Message-ID: <7vobg04ebe.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vsj5c4exz.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 10 quoted lines

> 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.

This is unrelated to the case you mentioned, but I wonder what happens if you did this:

 * You are on branch 'next', where foo.c includes (perhaps
   indirectly) frotz.h.  Compile and you get foo.o and also the
   dependency recorded for it, "foo.o: foo.c frotz.h", in the
   .depend/foo.o.d file.

 * You check out branch 'master', where foo.c does not include
   frotz.h.  Indeed, the include file does not even exist on the
   branch.

Do we get confused, because Makefile includes the depend file from the previous build, finds that you need foo.c and frotz.h up to date in order to get foo.o, but there is no rule to generate frotz.h?