On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne <sylv...@datastax.com>wrote:
> 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. > I don't see this as a problematic, given all the tools like git log --graph and graphical history viewers. Especially since long nitpick histories like this are not likely to be very common in practice. Would you care to elaborate on the issue? 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. > Does "look like shit" here mean "has lots of forks and merges", or "has lots of commits", or "is not aesthetically pleasing"? p
