I ran across the term 'patch bombing' today, which could be defined as; "multiple application logic changes all rolled into a single source code commit", it's the opposite of an 'atomic change'
I found the term relevant to a background thought I've been pickling over lately....
It's not uncommon for me to be in the middle of adding a new feature when I run across a bit of crufty code that needs to be refactored. Which poses the problem; How do I do the refactoring with out mixing the change sets?
In the past I'd just make both changes and write one fat commit message explaining everything but I always thought this approach smelled bad. Then, Jay Fields blogged about 'using patch as subversion's stash' and turned me on to 'the power of git-stash'.
It turns out that Bazaar, which I'm using for my current project, doesn't directly support this operation either but Jay's patch-stashing approach works just as well for bzr as it does for svn.
Feb 23, 2008
Patch Bombing and Change Stashing
Subscribe to:
Post Comments (Atom)
1 comment:
Perhaps shelve from bzr-tools might be of use to you in this situation.
It will allow you to put everything you've been working on aside, i.e on the shelf. You can then clean up that bit of cruft you came across and commit it in a straightforward change. Unshelve your previous work and continue.
Post a Comment