Re: Segmentation fault with latest git (070c57df)

[Jeff King <peff@peff.net>]

On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote:

> On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote:
> 
> > 허종만 <jongman.heo@samsung.com> writes:
> > 
> > > But usually when I build upstream Linux kernel, I don't do "make
> > > clean" after git pull..  I didn't expect that I needed "make
> > > clean" for git build.
> > 
> > We don't expect anybody need "make clean", either.  There is
> > something wrong in the dependency.
> 
> Agreed, but I cannot see what. If auto-header-dependencies is on, gcc
> should find it (it is not even a recursive dependency for
> builtin/fetch.c). And if it is not on, we should rebuild based on LIB_H,
> which includes string-list.h (and always has, as far as I can tell).

By the way, while researching this issue, I noticed this:

-- >8 --
Subject: [PATCH] Makefile: add version.h to LIB_H

This was forgotten when the file was added by 816fb46, and
not noticed because most developers are on modern systems
that support COMPUTE_HEADER_DEPENDENCIES.  However, people
still relying on LIB_H for dependencies might have failed to
recompile when this file changed.

Found with "make CHECK_HEADER_DEPENDENCIES=yes".

Signed-off-by: Jeff King <peff@peff.net>
---
I don't see how this could have caused the issue at hand, but it is good
to fix nonetheless. I almost wonder if LIB_H should just be set to
$(wildcard *.h) or similar, since that is what ends up going into it.
And then we would not have to deal with manually keeping it up to date.

 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 731b6a8..6b42f66 100644
--- a/Makefile
+++ b/Makefile
@@ -704,6 +704,7 @@ LIB_H += varint.h
 LIB_H += userdiff.h
 LIB_H += utf8.h
 LIB_H += varint.h
+LIB_H += version.h
 LIB_H += walker.h
 LIB_H += wildmatch.h
 LIB_H += wt-status.h
-- 
1.8.1.2.11.g1a2f572