Re: [BUG] Git bisect not finding the right commit

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2012, 18:09 UTC
Message-ID: <7vk44mfdow.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87ehuu958d.fsf@franz.ak.mind.de>

andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:

Show 28 quoted lines

>>>>>> On Thu, 19 Jan 2012 09:23:01 +0100, Johannes Sixt <j.sixt@viscovery.net> said:
>
>  js> Am 1/19/2012 4:29, schrieb Andreas J. Koenig:
>  >> - A -> B      ->     C - D ->
>  >>          \         /
>  >>           - E - F -
>  >> 
>  >> A v5.15.5
>  >> B v5.15.5-20-gfd76d40
>  >> C v5.15.5-81-gcfe287a
>  >> D v5.15.5-159-ga71d67b
>  >> E v5.15.4-110-g27b29ec
>  >> F v5.15.4-169-g3582575
>
>  js> I haven't looked at the actual history, but given the names of the commits
>  js> as produced by git-describe, I doubt that your history graph sketched
>  js> above is correct. Doesn't it look more like this:
>
>  js>       A -- B -- C -- D --
>  js>      /         /
>  js>  -- X -- E -- F
>
>  js> where X is v5.15.4?
>
> Yes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58
> and since there was a long timespan between the start of the development
> of the code and the merge (May-Nov), the gitk presentation got a bit
> complex to read.

(This is somewhat off-topic, so Andreas is on Cc: and the list is on To:)

I doubt --simplify-by-decoration alone would make it easier to view such a complex and long history, but I wonder if we can use the same logic to help users in a case like this. Instead of only keeping tagged versions in the result to show topology, perhaps we can allow the user to feed a list of "key points in history" as command line arguments and apply the same kind of simplification to help visualizing the topology?