On Wed, Dec 19, 2007 at 01:04:41PM -0800, SJS wrote:
Unless you have 'ownership of code' -- where one developer has sole responsibility for changes to a set of files -- private branches just don't seem that beneficial. Better to keep the code *always* compiling (and with unit tests, always running, correctly).
The developers on my team now love them, and I think many will continue using git, even if it is just a front end for something else. Always compiling is a good thing, unit tests are a good thing, but that doesn't mean I want to push my change out right away. But, it is also a good thing to be able to work on my changes, review it, clean it up, possibly even refactor it, and have the changes kept together as a group. I have private branches, but they usually don't live all that long. Larger branches tend to cause lots of time to be spent merging (which is what I'm doing now). I think some depends on how you view the history. I view the history a lot. I use 'blame' to figure out what caused something to change. I read people's change descriptions to find out why they did something. It is very frustrating to find the log message is something like: "Changed foo()". My general advice is that the developer shouldn't be anything in the change description that isn't obvious from a diff. It's obvious from the diff that foo() changed, I want to know why. Dave -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
