git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Sverre Rabbelier <srabbelier@gmail.com>
To: Michael Witten <mfwitten@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Patching bad commits
Date: Tue, 29 Jun 2010 00:24:18 +0200	[thread overview]
Message-ID: <AANLkTikfrAk9xDNhcHDJupuWBKrxExKE1N78rJWDTUYF@mail.gmail.com> (raw)
In-Reply-To: <4c291e41.4f1ee30a.3484.fffff729@mx.google.com>

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

      parent 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
2010-07-05  8:37   ` Antriksh Pany
2010-06-28 22:24 ` Sverre Rabbelier [this message]

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=AANLkTikfrAk9xDNhcHDJupuWBKrxExKE1N78rJWDTUYF@mail.gmail.com \
    --to=srabbelier@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).