On Mon, Jun 16, 2008 at 03:25:51PM -0700, Lan Barnes wrote:
The "cost" of branching has nothing to do with computer resources. It has to do with assaults on logical clarity. If you branch willy-nilly on every whim just because the tools make it easy, your project will descend into the chaos of idiosyncratic development with code snippets of value scattered in hundreds of little windy tunnels, all alike. Of course, some developers like that.
Some call it speculation or experimentation. But, I agree, these kinds of things shouldn't live for long periods of time. I tend to have a single branch for my active development, with changes getting pulled into the mainline as they are reviewed. If I'm going to work on something that takes more than one commit, it will get its own branch. I may squash the commits together before anyone sees it, depending on what is appropriate. I usually won't be able to tell what is appropriate until after I've worked on it for a while. To me, what is more important about git branches isn't that they are free, or that you can make lots of them, but that until I push my changes to someone else, I can _edit_ my changes. In reality, it is implemented by branching each time, and discarding the old branch, but it feels just like I'm able to edit my history. It's really just an extension of how something like a P4 workspace lets you work on files until you are ready to commit, only here I get to work on a sequence of commits until I am ready to push them.
I wonder how many branch lovers have ever been asked to do a complex code merge across a span of several branches with scattered common ancestors?
Well, I have, and it isn't fun. But, I wish more people would have to go through the process. I just haven't found any other way of explaining to someone what proper commit/patch granularity should be, short of having them have to do merges. I strongly feel that developers should be more focused on what their change is rather than just dropping code in. So many people commit without even looking at the diffs. The merge person has to deal with all of the pointless cruft changes that have no effect on the code. Worst is the person who changes tabs and spaces while also making other changes to the file. David -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
