Mercurial: What is the benefit of fixing errors in earlier versions

Question

According to the guide, under the heading: Fixing errors in earlier revisions, it states this:

When you find a bug in some earlier revision you have two options: either you can fix it in the current code, or you can go back in history and fix the code exactly where you did it, which creates a cleaner history.

1. How does going back in history make it cleaner? It still makes a new changeset at tip.
2. Does it have something to do with what is recorded as it's parent?
3. Is there a way to view the logs seeing the newly inserted changeset in that order?
4. This lesson is under the main heading of Lone developer with nonlinear history. Is this good practice when working on a team?

Answer 1

I'm more familiar with subversion, but if you are allowed to make changes in "the past" then that would mean that you can alter all branches of a specific repository.

In other words, if you make a mistake in revision 100, and branch the code, the mistake will persist in both branches. Instead of fixing the code in both branches separately, you could fix the mistake once, in revision 100, and have it propagate down both branches.

Answer 2

1) It makes it cleaner by providing the fix closer to the creation of the bug. Thus, if you had multiple clones after the bug, each could pull in the fix changeset(s) which don't include any code related to subsequent changes. It does create a new changeset (tip). You will then want to merge that fix with all clones where relevant.

2) Yes. Because you're cloning the code where the bug was created, the revision history refers directly to the changeset where the bug originated, so it helps document (directly and not just through comments) why the change exists.

3) The changeset will never appear inserted - it must always be merged later in the tree, just as any other clone would be merged.

4) I don't see this approach as diverging from any team approach. In either case, you would need to communicate with the team to indicate where the fix is, or it would be in some master repository where you could merge the fix. I would say this approach is applicable in team environments.

Answer 3

It’s cleaner in the sense of being more informative. You’ll end up with a merge commit which shows you via its parents exactly where the bug was introduced and where you removed it.

It’s also cleaner in the way that you’ll have a commit which solely removes the bug and take care about the merging stuff afterwards. That is, when you just fix the bug in the newest version of your code, you’ll have to do both bug fixing and taking care of new stuff at the same time, which makes it less clear, what the actual fix has been.