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@xxxxxxx> > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
