> 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
