Re: Opinions on bug fix organisation

From: Brian Gernhardt <benji@silverinsanity.com>
Date: May 16, 2007, 14:46 UTC
Message-ID: <5C14809D-14D9-4FC9-B8D5-FDBFDA89A369@silverinsanity.com>
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>

On May 16, 2007, at 6:38 AM, Andy Parkins wrote:

Show 10 quoted lines

> 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?

I just encountered this myself with one of my repos. I'm developing solo so I could just rebase if I felt like it, but don't like developing that habit, so I'm probably going with the second one. But that's because of how I'm developing it. My master has undergone serious changes recently (since the bug commit), so I'm going back and checking out the bug commit to focus on that issue without anything else that's been changed since then.

My personal feeling is that the commit should reflect how the fix was developed. If it's simple fix that you simply wrote on top of the full branch, commit it that way. If you had to (or wanted to) go back and develop on top of the original commit, commit it that way. Usually I'll just commit on top of master, but if either I need to remove other complications from the fix or need to introduce the fix (but not everything else) into multiple branches, I'll do the merge.

~~ Brian