I'm by no means a git guru, but just happened to attend a meeting last night where the presenter addressed this exact issue. He has a pretty slick process that kept the master/trunk clean without rebasing by squashing a set of commits into a single commit when merged to trunk. (using git squash?)
I'm CCing the guru, Nicholas Hance. Nicholas, can you share that process handout from last night? -brian On Thu, Jan 5, 2012 at 11:58 AM, Sylvain Lebresne <sylv...@datastax.com>wrote: > > This discourages collaboration because anyone that might fork > > github.com/author/666 is sitting on a powder keg. > > Alright, but then what is it you're proposing? > > > At best it's yak shaving. At worst it's going to result in some very > > frustrated contributors. This is one of the major reasons why rebase > > is so contentious, and it's exactly why you hear so many people saying > > "don't rebase branches that have been published". > > Again, I was more talking about the only reasonable solution I saw. > Because to be clear, if the history for some issue 666 in say trunk looks > like: > > commit eeee: last nits from reviewer > commit dddd: oops, typo that prevented commit > commit cccc: some more fix found during review > commit bbbb: refactor half of preceding patch following reviewer comments > commit aaaa: Do something awesome - patch for #666 > > then imho that's a big regression from current patch based development. > > So basically my question is how do we meld all those commits that will > necessarily happen due to the nature of distributed reviews so that our > main history don't look like shit? And if the answer is "we don't" then > I'm not too fond of that solution. > > -- > Sylvain > -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/
