[infinispan-dev] Infinispan 7.1 plan

[Tristan Tarrant]

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