samza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Riccomini <criccom...@linkedin.com>
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.

Cheers,
Chris

On 8/16/13 9:48 PM, "Jakob Homan" <jghoman@gmail.com> 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
><criccomini@linkedin.com>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" <criccomini@linkedin.com> 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" <jay.kreps@gmail.com> 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
>> >
>>
>>


Mime
View raw message