On Tue, Jul 26, 2011 at 4:14 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jon Seymour <jon.seymour@xxxxxxxxx> writes:
>
>> 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:
>
> What prevents your disk from corrupting a blob that was in B6, modified by
> commit B7, and then _reverted_ by commit B8? Then your checkout would fail
> at B6 and B8 but B7 will be fine.
But that's ok.
If B7's tree is fine, then the tree at B7 (if not the exact history
leading to the tree)
can be recovered by suitable grafts.
Also, the intent was not to use failure of git checkout as the test -
the intent was merely
to prevent a failure of git checkout from progressing the bisection.
The test for badness is something that would be run at each point in
the process.
I admit that git status is not a good test, since it is possible that
git update-ref --no-deref <target>
&& git checkout <target> will not restore a clean working tree and
index at each step,
even for good commits.
Of course, this is all rather academic since I agree your suggestion
of a --no-checkout option is a more general purpose solution
which can do all that --ignore-checkout-failure does and more.
>
> As I wrote in my footnote, if your test is to find the most recent commit,
> starting from which all the objects reachable from it are not corrupt (by
> using "rev-list --objects $commit | pack-objects"), you could run your
> bisect by somehow first finding a good commit (B5) that passes the test,
> and after knowing a bad commit (B8) that does not pass (because it is
> missing the single blob that is unreadable for B6 and B8), and then bisect
> using a slightly less expensive test
>
> rev-list --objects B5..$commit | pack-objects
>
> to find it in theory, but "Being unable to check-out" is not an isolated
> event and cannot be used as the check as you seem to think.
>
I agree - a test that actually traverses the graph reachable from the
commits each tree and visits each object is better.
I'd tweak your snippet with --max-count=1, so that amount of work per
commit is limited.
Note that running git bisect --no-checkout will still be useful here
since it will limit the number of iterations that need to
be tested in order to find B5, for example.
>
> Pros of using HEAD (i.e. the only change under the new mode would be that
> we do not touch the index nor the working tree) is that the test you would
> need to run in each step of bisection can use the familiar HEAD ref
> instead of a strange BISECT_CURSOR, "bisect reset" will take you back from
> the tentative detached HEAD state the usual way, and most likely the
> necessary change to git-bisect.sh would be smaller. Cons of using HEAD
> would be that the index and the working tree will be totally out-of-sync
> with respect to HEAD during the bisection (by definition---as that is the
> point of this new mode). One could argue that a naïve user might get
> confused, but I am not sure how big a practical downside it would be.
>
>
How about a compromise such as:
--no-checkout[=<ref>]
which defaults to HEAD, but can be specified as something else?
jon.
--
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