samza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Riccomini <>
Subject Re: commit style
Date Sat, 17 Aug 2013 05:43:23 GMT
Hey Guys,

Sounds pretty unanimous. Squashing for JIRA, RB, and commits. Anyone else
have any feedback? Otherwise I'd say, case closed.


On 8/16/13 9:48 PM, "Jakob Homan" <> 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
>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
>> Hey Guys,
>> Reading over:
>> I definitely prefer a squashed .patch on JIRA, and a squashed RB, as
>> 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" <> wrote:
>> >Hey Jay,
>> >
>> >Good point.
>> >
>> >I suspect RB will prefer the squashed style. I think JIRA will prefer
>> >as well (SAMZA-14.0.patch), right? What do other projects do?
>> >
>> >Cheers,
>> >Chris
>> >
>> >On 8/15/13 4:36 PM, "Jay Kreps" <> wrote:
>> >
>> >>We have been using sort of different git styles. I think Chris has
>> >>checking in rapidly. I do lots of quick commits but then rebase it
>> >>one
>> >>giant patch for review.
>> >>
>> >>Do we have a preference? I am fine either way. For code review the
>> >>commit style is actually nicer because the git format-patch command
>> >>then actually show the original patch plus the changes made in
>> >>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
>> >

View raw message