On Wed, December 19, 2007 1:30 pm, David Brown wrote: > 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
The canonical reason for a branch is development of code that should not be mixed with the main branch. For example, when a release is close, a branch can allow developers who are finished with their input to begin on the feature set for the next release. When the release is final, the branch becomes the main line. Another would be (where I currently work) adding a feature specifically for a show, but that might not make it into the product if it bombs at the show. Matt can help me with this, but since p4 is a "branch on checkout" model, it really isn't that hard to create a new branch. You simply integrate your changed file to the new branch, which creates it and retains history. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
