From: Johannes Sixt <j6t@kdbg.org>
To: Jon Seymour <jon.seymour@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [RFC 0/9] bisect: allow git bisect to be used with repos containing damaged trees.
Date: Mon, 25 Jul 2011 20:48:36 +0200 [thread overview]
Message-ID: <4E2DBA84.3090405@kdbg.org> (raw)
In-Reply-To: <CAH3AnrrVwodvtwWfaJCJqjuHThtv75jaWeDjvwRgdFbgXA3ziA@mail.gmail.com>
Am 25.07.2011 11:28, schrieb Jon Seymour:
> On Mon, Jul 25, 2011 at 4:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jon Seymour <jon.seymour@gmail.com> writes:
>>
>>> ... In particular, it
>>> allows git bisect to be used to locate commits containing damaged trees.
>>
>> I am afraid it wouldn't allow it, and I am not going to take this series
>> that adds an option to bisect to ignore errors during checkout.
>
> Understand that you don't wish to accept the series, but I do think
> you are mistaken about whether it will work.
>
>>
>> Remember that bisection is to find a single event in the history whose
>> effect consistently persists in all the commits into the future from that
>> point. For example, if you have this history:
>>
>> ---A---B---C
>>
>> and there is a bitflip in a blob contained in the commit B's tree, you may
>> not be able to check it out. But that does _not_ mean you cannot check C
>> out due to a corrupt object in B. The change going from B to C may be to
>> remove that blob, for example. "A tree that refers to a corrupt object was
>> introduced by this commit" is not a single event whose effect cascades
>> through the history into the future [*1*].
>
> I don't think you understood my intention. Suppose, I have
>
> B4 - B5 - B6' - B7' - B8' - B9
>
> such that B6 and B7 and B8 all contain a damaged tree, but B4, B5 and B9 don't
> since it contains a different tree, then:
>
> git bisect start B8' B4 --ignore-checkout-failure &&
> git bisect run eval "git status >/dev/null 2>&1 || false"
>
> will stop with bisect/bad = B6'
>
> This is exactly the result I wanted, and I discover B6' with a binary
> search, rather than a linear search.
>
> (I could also discover B8' with a binary search by reversing the sense
> of the test).
The fundamental preconditions of bisection are: that there is a single
event in the sequence, and that the effects of the event propagate to
the end of the sequence.
Junio explainded, that the second precondition is violated. Therefore,
you cannot apply git-bisect to find brokenness in a repository *in general*.
Of course, there may be special cases where stronger assumptions are
justifiable, and your case may have been one of them.
-- Hannes
next prev parent reply other threads:[~2011-07-25 18:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-24 5:57 [RFC 0/9] bisect: allow git bisect to be used with repos containing damaged trees Jon Seymour
2011-07-24 5:57 ` [PATCH 1/9] bisect: add tests to document expected behaviour in presence of broken trees Jon Seymour
2011-07-24 5:57 ` [PATCH 2/9] bisect: introduce a --ignore-checkout-failure option to bisect--helper Jon Seymour
2011-07-24 5:57 ` [PATCH 3/9] bisect: implement support for --ignore-checkout-failure option Jon Seymour
2011-07-24 5:57 ` [PATCH 4/9] bisect: introduce a helper function to tolerate checkout failures Jon Seymour
2011-07-24 5:57 ` [PATCH 5/9] bisect: replace existing calls to git checkout with bisect_checkout_with_ignore Jon Seymour
2011-07-24 5:57 ` [PATCH 6/9] bisect: enable --ignore-checkout-failure in the porcelain Jon Seymour
2011-07-24 5:57 ` [PATCH 7/9] bisect: better diagnostics, in case of mis-typed option Jon Seymour
2011-07-24 5:57 ` [PATCH 8/9] bisect: add tests for --ignore-checkout-failure option Jon Seymour
2011-07-24 5:57 ` [PATCH 9/9] bisect: add documentation " Jon Seymour
2011-07-24 8:05 ` [RFC 0/9] bisect: allow git bisect to be used with repos containing damaged trees Johannes Sixt
2011-07-24 8:54 ` Jon Seymour
2011-07-24 18:35 ` Junio C Hamano
2011-07-25 9:28 ` Jon Seymour
2011-07-25 18:14 ` Junio C Hamano
2011-07-25 23:27 ` Jon Seymour
2011-07-25 18:48 ` Johannes Sixt [this message]
2011-07-25 23:38 ` Jon Seymour
2011-07-26 7:43 ` Jakub Narebski
2011-07-26 8:26 ` Jon Seymour
2011-07-26 13:28 ` Jon Seymour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E2DBA84.3090405@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jon.seymour@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).