samza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <jgho...@gmail.com>
Subject Re: commit style
Date Sat, 17 Aug 2013 04:48:26 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message