Re: Patching bad commits

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jun 28, 2010, 22:23 UTC
Message-ID: <AANLkTimAAtO9p2rQW4pITKQehhYF6pppBUgPxoyrLOvA@mail.gmail.com>
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:

Show 6 quoted lines

> 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