git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Avery Pennarun <apenwarr@gmail.com>
To: Michael Witten <mfwitten@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Patching bad commits
Date: Mon, 28 Jun 2010 18:23:44 -0400	[thread overview]
Message-ID: <AANLkTimAAtO9p2rQW4pITKQehhYF6pppBUgPxoyrLOvA@mail.gmail.com> (raw)
In-Reply-To: <4c291e41.4f1ee30a.3484.fffff729@mx.google.com>

On Mon, Jun 28, 2010 at 6:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
> Sometimes bisecting is less than useful because a number of commits
> fail to build.
>
> How about implementing something SIMILAR to "git notes" (perhaps
> even using "git notes") to store and apply patches for such bad
> commits?

You could probably use the (relatively new) 'git replace' feature for
this.  Just replace the broken tree object with a new one that doesn't
have the bug.  I've never tried it, but it does seem like it should
work.

That said, this idea would require you to manually patch every single
commit that ever had a problem.  I'm not sure there's much benefit to
that compared to the overwhelming cost.  I think it might be more
useful - and much easier -to just have a permanent "always skip these
commits when bisecting" list.  (I don't think such a feature exists
yet though.)

Btw, in recent versions of git, 'git bisect skip' is pretty smart and
seeks around in the tree in such a way that it doesn't hurt so much
when you have a batch of bad commits somewhere in the middle.  So you
may find that it's really not that bad to just use 'git bisect skip'
occasionally if your version of git is relatively new and your history
isn't absolutely littered with crap.

Speaking of littering your history with crap, the an ounce of
prevention is worth a pound of cure: make sure all your commits pass
unit tests before committing, and you'll rarely have this problem
anyway :)  That's obviously easier said than done however.

Have fun,

Avery

  reply	other threads:[~2010-06-28 22:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28 22:03 Patching bad commits Michael Witten
2010-06-28 22:23 ` Avery Pennarun [this message]
2010-07-05  8:37   ` Antriksh Pany
2010-06-28 22:24 ` Sverre Rabbelier

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimAAtO9p2rQW4pITKQehhYF6pppBUgPxoyrLOvA@mail.gmail.com \
    --to=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mfwitten@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).