On May 16, 2007, at 6:38 AM, Andy Parkins wrote:
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
-
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
