From: Andy Parkins Date: Wed, 16 May 2007 10:38:28 GMT Subject: Opinions on bug fix organisation Message-ID: <200705161138.30134.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