On Dec 3, 2009, at 11:36 AM, Adam Heath wrote: > David E Jones wrote: >> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote: >> >>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote: >>> >>>> If you want to review these commits why not check them in the birt >>>> branch...there they are separated. >>> I'm not so concerned about myself but more for others and in particular >>> people looking at the commit history in the future. >>> The integration and the examples are completely different subject matters >>> are should be treated as such when committing to the trunk regardless of >>> how they've been committed to the branch. >> >> How would one separate them when committing them to the trunk? >> >> Typically merging a branch with the trunk involves a single commit in order >> to keep it simple. It doesn't have to be that way, but it nice to simply say >> branch rev X was merged into the trunk at trunk rev Y. > > You may not have noticed, but I've done several bulk commits with > git+svn. I'll do a whole bunch of work, then when everything is > finished, and I've doing various testing at each individual point in > the chain, I'll flood svn with several commits back to back. You'll > see all the individual, *small* changes, as I first fix bugs, rename > methods, make things private from public, then finally remove whole > swaths of code. Look at the UtilCache stuff I did recently, where I > made the constructor(s) private.
That's great Adam, but not how branches are generally done. There is already a revision history in the branch, so why duplicate that in the trunk instead of doing a more traditional, easy, and clean merge? In fact, I like branches better if you want to collaborate with others. If you don't it doesn't really matter I suppose. -David
