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@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
