(Unsolicited hint) straightening out stray "git bisect"

From: Junio C Hamano <junkio@cox.net>
Date: Aug 9, 2006, 19:30 UTC
Message-ID: <7vodut3dwn.fsf_-_@assigned-by-dhcp.cox.net>
In-Reply-To: <7vwt9h3e35.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 19 quoted lines

> Junio C Hamano <junkio@cox.net> writes:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> First (noticed by matled) is that for git-diff-tree with single tree
>>>> as an argument it outputs fist commit-id of commit given at input. 
>>>> It is not mentioned in documentation and I think totally unnecessary:
>>>>
>>>> 1038:jnareb@roke:~/git> git diff-tree --abbrev origin
>>>> d5dc6a76d49367cddc015e01d2e9aa22e64d7e28
>>>> :040000 040000 44fb36d... 1c26294... M  Documentation
>>>
> Turns out that git-diff-tree from 1.0.0 behaves this way.  Since
> 7384889 (May 18, 2005), one-tree form of diff-tree showed the
> "header" line that has the commit object name at the top, and
> since 1809266 (Jun 23, 2005) we have exactly one commit object
> name there; before that we used to say "commitA (from commitB)".

BTW, I got curious and run "git bisect" to see when the " (from commitB)" was dropped. This turned out to be quite an interesting one. You would start from these:

        $ git bisect start
        $ git bisect good 7384889 ;# this said "( from commitB)"
        $ git bisect bad v1.0.0   ;# we know this did not

and keep building and testing "git-diff-tree", to mark the ones that do not say "( from commitB)" as bad and the ones that do as good.

At some point, it crosses the "coolest merge ever" and suggests c2f6a02 to be checked, which is on the original "gitk" branch. There is no way to build git-diff-tree in that revision ;-).

At this point, "visualize" helps.

	$ git bisect visualize

shows (pardon the ASCII art):

    *--bisect/bad git-rev-list: add option to list all objects
    *  git-rev-parse: re-organize and be more careful
    .
    *  Do a cross-project merge of Paul Mackerras' gitk visualizer 
    |* Try to assign colors so crossing lines have different colors
    |* Account for indentation of the checkin commments by git-rev-list
    |.
    |*-bisect Show heads as well as tags
    |.
    |* Add initial version of gitk to the CVS repository
    o--bisect/good-fae22ac [PATCH] git-apply: tests for --stat and --summary.

Now, we know that gitk did not have diff-tree, so up to the commit "Try to assign colors..." are irrelevant to the "bug" we are hunting. We say:

	$ git bisect good 6c20ff3

(where 6c20ff3 is the commit "Try to assign colors...") to mark everything leading to that commit (ones on the line on the right hand side in the above ASCII graph) are good. After that bisect continues normally.