Opinions on bug fix organisation

[Andy Parkins <andyparkins@gmail.com>]

Hello,

This is not so much a question about git, but more about history organisation.  
I'm undecided on the best way to deal with bug fix history.

Imagine this situation:

 * -- * -- B -- * -- * -- *

"B" is a commit that introduced a feature and a bug, that bug is present 
forever more in history (which I think is good - history is history).  I've 
pushed the repository to the rest of the developers in the meantime, so there 
is no editing "B" and doing some rebase magic.

Now, I want to make a commit that fixes that bug.  These are the options:

 * -- * -- B -- * -- * -- * -- F

 or

 * -- * -- B -- * -- * -- * -- M
            \                 /
             --------------- F

That is - just commit a fix or, commit the fix, "F", directly on "B" then 
merge that fix back to HEAD with "M".

I quite like option 2 because it records intent - i.e. "I wish I could have 
gone back and changed this revision, but I can't", but it makes a more 
complicated history.

What do people think?



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com