From: Jeff King <peff@peff.net>
Date: Wed, 20 Jan 2010 00:41:46 GMT
Subject: Re: git-status segmentation fault in master / OS X
Message-ID: <20100120004146.GB16824@coredump.intra.peff.net>
In-Reply-To: <57518fd11001190959n355a0f22p7caa7251b705efaf@mail.gmail.com>

On Tue, Jan 19, 2010 at 05:59:51PM +0000, Jonathan del Strother wrote:

> I've been running into a segmentation fault on running git status in
> my repository while there are staged changes.

I can't reproduce it here. Is there anything else interesting about the
repo you can tell us besides that it has staged changes?

> Bisecting suggests it was introduced in:
> 
> commit 73d66323ac78c750ba42fef23b1cb8fd2110e023
> Merge: 054d2fa 8740773
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Wed Jan 13 11:58:34 2010 -0800
> 
>     Merge branch 'nd/sparse'
> 
> 
> The last commit from nd/sparse (8740773) is fine, so I guess it's a
> bad merge...?

Could be a bad interaction between commits on nd/sparse and whatever was
done since it had branched. You can try rebasing nd/sparse and bisecting
a linearised version, like this:

  bad_merge=73d66323
  # pretend we are on nd/sparse
  git checkout -b test $bad_merge^2
  # rebase onto what we merged onto
  git rebase $bad_merge^1
  # now bisect. what we have now is presumably
  # bad (though you should probably double check)
  # and from the previous bisect we know that
  # everything pre-merge is good
  git bisect start
  git bisect good $bad_merge^1
  git bisect bad

-Peff