From: Johannes Sixt <j6t@kdbg.org>
To: Jon Seymour <jon.seymour@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC 0/9] bisect: allow git bisect to be used with repos containing damaged trees.
Date: Sun, 24 Jul 2011 10:05:37 +0200 [thread overview]
Message-ID: <4E2BD251.6060306@kdbg.org> (raw)
In-Reply-To: <1311487074-25070-1-git-send-email-jon.seymour@gmail.com>
Am 24.07.2011 07:57, schrieb Jon Seymour:
> Currently git bisect assumes that the respository to be undamaged. This limits the usefulness
> of git bisect when working with damaged repositories.
So, what? Isn't a broken repository also (almost) useless w.r.t. log,
checkout, rebase, reset, push, fetch...?
> This series introduces an option, --ignore-checkout-failure, which can be used with
> "git bisect start" to indicate that checkout failures should be tolerated for the life
> of the (new) bisection process. This allows git bisect to be used on damaged repositories. In
> particular, it allows git bisect to be used to locate commits containing damaged trees.
I have to wonder: why do you care only about git-bisect? If you want to
be able to use a broken repository, aren't there many more commands that
fail and for which you also want to have a similar work-around? Or is
git-bisect the only one where the work-around was missing?
> If the --ignore-checkout-failure option is specified, then if git checkout fails either
> at the start of the bisection process or later while probing a new trial commit, then the
> checkout failure will be noisily ignored and the HEAD reference will be updated to the
> intended commit. This may leave the working tree and index in an inconsistent state
> w.r.t the HEAD commit.
But what is an inconsistent state good for? In general, it makes no
sense to decide whether the result is "good" or "bad" when you know in
advance that the checked-out state is inconsistent.
-- Hannes
next prev parent reply other threads:[~2011-07-24 8:05 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 ` Johannes Sixt [this message]
2011-07-24 8:54 ` [RFC 0/9] bisect: allow git bisect to be used with repos containing damaged trees 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
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=4E2BD251.6060306@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--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).