Hey Guys, Sounds pretty unanimous. Squashing for JIRA, RB, and commits. Anyone else have any feedback? Otherwise I'd say, case closed.
Cheers, Chris On 8/16/13 9:48 PM, "Jakob Homan" <[email protected]> wrote: >RB can diff between patches (so you can just look at what's happened >between v1 and v2, for instance). I don't believe this will work if the >patches are non-squashed. > >Not squashing on commit will be a real pain in the (under RTC) rare >occurences we need to revert patches. For non-major changes, ie those >that >would warrant a separate development branch in Subversion-land, I find >unsquashed commits just introduce a lot of noise that doesn't add to the >record. It'd be nice if git could 'zoom out' and only show the >intermediate commits when asked. I'd recommend squashing. > > >On Fri, Aug 16, 2013 at 8:03 PM, Chris Riccomini ><[email protected]>wrote: > >> Hey Guys, >> >> Reading over: >> >> https://issues.apache.org/jira/browse/SAMZA-14 >> >> I definitely prefer a squashed .patch on JIRA, and a squashed RB, as >>well. >> The un-squashed v2 patch on SAMZA-14 is a bit hard to follow. >> >> Whether we squash them on commit, I'm undecided on. >> >> Cheers, >> Chris >> >> On 8/15/13 4:41 PM, "Chris Riccomini" <[email protected]> wrote: >> >> >Hey Jay, >> > >> >Good point. >> > >> >I suspect RB will prefer the squashed style. I think JIRA will prefer >>this >> >as well (SAMZA-14.0.patch), right? What do other projects do? >> > >> >Cheers, >> >Chris >> > >> >On 8/15/13 4:36 PM, "Jay Kreps" <[email protected]> wrote: >> > >> >>We have been using sort of different git styles. I think Chris has >>been >> >>checking in rapidly. I do lots of quick commits but then rebase it >>into >> >>one >> >>giant patch for review. >> >> >> >>Do we have a preference? I am fine either way. For code review the >>quick >> >>commit style is actually nicer because the git format-patch command >>will >> >>then actually show the original patch plus the changes made in >>response >> >>to >> >>feedback each as different commits. The problem with this is that your >> >>history gets pretty hard to understand. The big patch way gives a very >> >>clean version of history but makes code review a bit harder. >> >> >> >>I am cool with either or both. >> >> >> >>Not sure how git format-patch interacts with review board... >> >> >> >>-Jay >> > >> >>
