Rewriting history makes you look good

One thing I dislike about rewriting history in version control systems: it makes you look smarter than you are.

Let's imagine that you are developing a feature F. So, starting from the trunk, you do it on a branch

    trunk -> F1 -> F2 -> ...

Then you realize there is a bug in the trunk is something you depend on.  You fix that, but still on your branch


    trunk -> F1 -> F2 -> bugfix_in_F

You want to put that bugfix onto the trunk as soon as possible, so you apply t to the trunk.  Now we really have a branch:


    trunk ---------------------------------> bugfix
          \                                                     /
           +->F1 -> F2 -> bugfix_in_F ->+

then eventually you merge the feature

    trunk ---------------------------------> bugfix -----> F
          \                                                  /                /
           +->F1 -> F2 -> bugfix_in_F ------> F3 -> F4

on the trunk the bugfix and the feature appear out of order - at least, out of historical order.  But at least you can see the way things were really done.

(Of course, Mercurial doesn't really support moving a bugfix like this from a branch to the trunk.  It's a partial merge.  Hint: don't use hg merge - that's a full merge - you'll get the feature F1 and F2 as well as the bugfix.   And if you undo that stuff before checking in the isolated bugfix, mercural will remember that, and make it hard to merge the feature later.

       If you are lucky, the partial merge is at file granularity. You can do 

hg update -r default; hg revert -r FeatureBranch file-that-was-bugfixed.cpp; test ...

      If less lucky, merge by hand, cherrypick, edit patch files.  ...

      Or just redo.

)

But apart from Mercurial's not supporting partial merges,

what I really dislike is stripping the branch away from the history,

leaving

trunk ---------------------------------> bugfix -----> F

       

Now, it looks like you were smarter than  you actually were: the bugfix happened out of the blue.

Worse...  working with a group like my present project that is not test-driven, you may not have a failing test for the bugfix.  Or, the failing test for the bugfix may only be integrated when you get the feature.

Sure, don't do that. I wish my project was test driven.  But ...

Must rewrite Michael Feathers' Legacy Code book.