On Thu, Jan 5, 2012 at 10: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?
That we use rebase on private topic branches as a courtesy to reviewers (or to streamline the process in general). That once that branch has been published, we no longer rebase it. I also think that a measure of common sense could be applied. If the review is particularly arduous, the reviewer and reviewee could agree to create a new branch (say 666-1) that (privately) rebases/squashes/etc changesets to complete the final step(s). Not as a tool for maintaining some standard for aesthetics in the version history, but to facilitate review. >> 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 Which is reality, isn't it? I know it's a contentious argument, but this *is* the history of the change. > then imho that's a big regression from current patch based development. If it is a goal to maintain some objective target for version history aesthetics, then yes. I say aesthetics here because I still don't understand the arguments about it obscuring history or making bisects impossible (and because you later go on to refer to it as "look[ing] like shit" :) ). The other side of the equation is that there is tremendous power to be had from distributed versioning, and this proposed workflow discourages taking advantage of that. > 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. I would argue that our deliverable should be beautiful code, not a beautifully formatted change history. -- Eric Evans Acunu | http://www.acunu.com | @acunu
