git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Patching bad commits
@ 2010-06-28 22:03 Michael Witten
  2010-06-28 22:23 ` Avery Pennarun
  2010-06-28 22:24 ` Sverre Rabbelier
  0 siblings, 2 replies; 4+ messages in thread
From: Michael Witten @ 2010-06-28 22:03 UTC (permalink / raw)
  To: git

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?

For instance, bisecting could transparently apply any patches that
are necessary to make a bad commit actually buildable; such patches
could be distributed as usual for the benefit of others.

I'm thinking that a "patch note" could have 2 forms:

    * A plain patch file (or maybe a git tree of patches).

    * A reference to another commit that should be checked
      out instead.

Is this a worthwhile idea?

Sincerely,
Michael Witten

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Patching bad commits
  2010-06-28 22:03 Patching bad commits Michael Witten
@ 2010-06-28 22:23 ` Avery Pennarun
  2010-07-05  8:37   ` Antriksh Pany
  2010-06-28 22:24 ` Sverre Rabbelier
  1 sibling, 1 reply; 4+ messages in thread
From: Avery Pennarun @ 2010-06-28 22:23 UTC (permalink / raw)
  To: Michael Witten; +Cc: git

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Patching bad commits
  2010-06-28 22:03 Patching bad commits Michael Witten
  2010-06-28 22:23 ` Avery Pennarun
@ 2010-06-28 22:24 ` Sverre Rabbelier
  1 sibling, 0 replies; 4+ messages in thread
From: Sverre Rabbelier @ 2010-06-28 22:24 UTC (permalink / raw)
  To: Michael Witten; +Cc: git

Heya,

On Tue, Jun 29, 2010 at 00:03, Michael Witten <mfwitten@gmail.com> wrote:
> How about implementing something SIMILAR to "git notes" (perhaps
> even using "git notes") to store and apply patches for such bad
> commits?

Definitely use 'git notes' for this, I'd say this is a perfect use
case for it. Just store the patches in their own notes ref and you're
good to go.

> For instance, bisecting could transparently apply any patches that
> are necessary to make a bad commit actually buildable; such patches
> could be distributed as usual for the benefit of others.

Something like that should probably be guarded by a
switch/configuration value, but that sounds very useful.

>    * A plain patch file (or maybe a git tree of patches).

I guess in this form 'git bisect' could just call 'git am' on that
tree (regardless of whether it has 1 or more patches), which would
apply them in the usual order? It might be useful to instead stream
the contents of the note to 'git am', but I could imagine it being
useful to have the patches on disk (so that you can edit them, or look
at them when applying fails).

>    * A reference to another commit that should be checked
>      out instead.

I'm not sure how useful that is, if you're just going to check out
another commit you might as well 'git bisect skip' the current one?
Well, I guess if the other commit is outside the bisect range but is
applied on top of the commit under inspection it makes sense. So makes
sense, only problem I see is that if that commit is on another branch
it might not be available locally.

> Is this a worthwhile idea?

I like this idea a lot, it's always bothered me that some commits can
just come up during git bisect as being untestable. The tricky part
will be to ensure that the patches you apply don't affect the bug ;).

-- 
Cheers,

Sverre Rabbelier

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Patching bad commits
  2010-06-28 22:23 ` Avery Pennarun
@ 2010-07-05  8:37   ` Antriksh Pany
  0 siblings, 0 replies; 4+ messages in thread
From: Antriksh Pany @ 2010-07-05  8:37 UTC (permalink / raw)
  To: Avery Pennarun; +Cc: Michael Witten, git

On Tue, Jun 29, 2010 at 3:53 AM, Avery Pennarun <apenwarr@gmail.com> wrote:
> 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.
>>

You could automate the process of skipping certain commits when build fails.
  make || git bisect skip
Automatically mark commits as bad when your test fails:
  ./test || git bisect bad
Otherwise 'git bisect good' is what you do.

I think you can put these together in a loop that works automatically
without much user intervention.

Hope this helps.

Cheers
Antriksh Pany

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-07-05  8:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-28 22:03 Patching bad commits Michael Witten
2010-06-28 22:23 ` Avery Pennarun
2010-07-05  8:37   ` Antriksh Pany
2010-06-28 22:24 ` Sverre Rabbelier

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).