git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Document 'git bisect fix'.

From
YDYann Dirson <dirson@bertin.fr>
Date
Mar 15, 2011, 10:16 UTC
Message-ID
<20110315111620.73108597@chalon.bertin.fr>
In-Reply-To
<20110314210001.GE4586@gmx.de>
Hi Ralf,

Maybe you should have made it more obvious that this patch is a RFC for a proposed feature (say, in subject line).

>'git bisect fix' teaches bisect about when some known bug was
>introduced and when it was fixed, so that bisect can merge in
>the fix when needed into new test candidates.

This sounds like a great idea. I do have myself to do conditional cherry-picks from bisect scripts, to deal with this problem.

>If some bug was fixed by a merge only, the more general notation
>"f_1 ^b_1 ^b_1' ..." could apply.
Some more precise example may make this case more clear.

+Fixing up known bugs +~~~~~~~~~~~~~~~~~~~~ + +If many revisions are broken due to some unrelated but known issue that +is easily fixed, you might want to prefer fixing it up temporarily.

It seems natural for "bisect run" to use this mechanism. What about the non-automated process ? We may want to get the fixes applied, or to only list available fixes to the user so he can "git merge" them manually, or maybe an interactive selection mode ? Probably something to be chosen via some config variable and flags, in a separate patch of the would-be series. But what happens initially will be a good thing to document.

+If `<commit1>` introduces a bug fixed by `<commit2>`, instruct bisect +to merge the latter before testing a commit that contains the former: + +------------ +$ git bisect fix <commit1>..<commit2> +------------

Usually, a bug also gets fixed by an official commit which does not fulfill the constraint of being branched at the faulty one. In this case you don't want to merge the fix if such a fix is already included, and thus you will need a way to specify "alternate fixes" to control this.

+A single `<commit>` acts as if `<commit>^..<commit>` was specified. +Fix statements can be repeated for every known bug, and are valid until +the bisection state is cleaned up with reset.

That is on the safe side, but we may at some point want some sort of "repository of fixes", where this info gets stored for easy reuse on subsequent bisections.

+Any bisect action that causes a new commit to be chosen will try to merge +the needed fixes and fail if they do not merge cleanly.

maybe "... similar to what happens when a bisect-run script terminates with exit code greated than 127." ?

-- 
Yann Dirson - Bertin Technologies
Previous: Ralf WildenhuesNext: Christian Couder
Message 7 of 10 in “git bisect plus fixes (was: PATCH: Add --size-check=[error|warning])”
  1. Ralf WildenhuesMar 14, 2011
  2. git-bisect.txt: example for bisecting with hotfixMichael J Gruber, Mar 14, 2011
  3. Junio C HamanoMar 14, 2011
  4. 1/2 git-bisect.txt: streamline run presentationMichael J Gruber, Mar 15, 2011
  5. 2/2 git-bisect.txt: example for bisecting with hot-fixMichael J Gruber, Mar 15, 2011
  6. Document 'git bisect fix'.Ralf Wildenhues, Mar 14, 2011
  7. Yann DirsonMar 15, 2011
  8. Christian CouderMar 16, 2011
  9. Michael J GruberMar 16, 2011
  10. Junio C HamanoMar 16, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.