Re: git blame crashes with internal error

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:

> On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:
> > 
> > On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> > 
> > > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > > > Bj?rn Steinbrink wrote:
> > > >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current
> > > >> master and all of them crashed. A small shell script to reproduce the
> > > >> problem is attached.
> > > >
> > > > Manual bisect? Ugh. This *is* the century of the competent developer
> > > > tools, you know... ;-)
> > > 
> > > Then, how do I search for a good version with git bisect if I only have
> > > the one data-point "master is bad"?
> > 
> > AFAIK Junio introduced the option to start with just a bad commit, and no 
> > known "good" one.
> > 
> > Yep, just found it.  Since v1.5.2-rc0~77^2(git-bisect: allow bisecting 
> > with only one bad commit.) it is supported.
> > 
> > >From the commit message:
> > 
> >     This allows you to say:
> > 
> >         git bisect start
> >         git bisect bad $bad
> >         git bisect next
> 
> OK, using that approach, I bisected it, and even found a "guilty"
> commit, although it is pretty much useless:
> 
> 1cfe77333f274c9ba9879c2eb61057a790eb050f is first bad commit
> commit 1cfe77333f274c9ba9879c2eb61057a790eb050f
> Author: Junio C Hamano <junkio@cox.net>
> Date:   Tue Jan 30 01:11:08 2007 -0800
> 
>     git-blame: no rev means start from the working tree file.

I think it is not useless.  It says exactly the same as I did, in another 
reply:  git blame starts with your working tree.  As such, it has to do 
some operations which happen to fail on unmerged files.

So the solution in your case _really_ is:

	git blame HEAD file2

Explanation: with that command line, you ask git blame to start with a 
given revision (instead of the working tree), which just so happens to be 
the HEAD revision.

Hth,
Dscho