[infinispan-dev] Infinispan 7.1 plan
Tristan Tarrant
ttarrant at redhat.com
Thu Oct 23 05:51:41 EDT 2014
On 22/10/14 12:29, Dan Berindei wrote:
> On Wed, Oct 22, 2014 at 1:32 PM, Galder Zamarreño <galder at redhat.com
> <mailto:galder at redhat.com>> wrote:
>
> Guys, Jason from Wildfly provided some interesting information a
> while back on the benefits of “merge” approach vs cherry-pick. To
> paraphrase:
>
> > 1. The original history from the author is preserved
>
>
> TBH most of the time I don't care about my history, I always have
> stupid commit messages until I squash my commits and "prettify" the
> commit messages.
Indeed: I commit and squash all the time. I'm only interested in seeing
multiple commits in the following case:
- they are actually subtasks of the main PR
- if the pull request is for a feature which was developed
collaboratively by multiple developers
> > 2. The author does not have to toss their branch to avoid a
> conflict introduced by a pull after their PR is merged
>
>
> I think this can only happen if the branch had conflicts and the
> committer resolved them, but we require authors to rebase so I don't
> think this has been a problem for us.
So the best approach seems to actually be rebase/pull, which gets us
what we want.
Tristan
More information about the infinispan-dev
mailing list