5

What is the best practice you encountered when wanted to fix a bug created in old commit?

Let suppose you have the following commits A->B->C->D and you discover that on commit B a bug was added.

[Edit: A, B, C and D were already published (pushed by others)]

Would you go back on B add the fix as a new commit B' and merge and get E:

A->B->C->D->E
 \->B'-----/

or add it the fix after D?

A->B->C->D->E

Stackoverflow suggests me that this might be a silly question but it's important to know what option you tried and what problems or benefit you got from that.

Alex
  • 5,510
  • 8
  • 35
  • 54

1 Answers1

4

If the commit in question is already pushed to another repository (Mercurial will track this using the commit phase), then I would simply make a new commit as a child of D. There is no real advantage of creating the bugfix as a child of B with a subsequent merge — noting in the commit message of E that this fixes a bug introduced in B works just as well.

If the commit that introduces the bug is still local (in the draft phase with Mercurial), then you should simply edit the commit before pushing it anywhere.

With Mercurial you use the included histedit extension for this:

$ hg histedit B

An editor opens to let you specify what you want done for each commit. Change pick to edit in the line corresponding to B. When you save the file and close the editor, the history editing begins. You can now fix the bug and run

$ hg histedit --continue

when you're happy with the result.

In Git you use a so-called interactive rebase for editing history:

$ git rebase -i B^

This starts the same process as for Mercurial. Change pick to edit and close the editor. Edit the files to your liking and amend the commit before continuing the history editing:

$ git commit -a --amend
$ git rebase --continue
Martin Geisler
  • 72,968
  • 25
  • 171
  • 229