Re: [infinispan-dev] Infinispan 7.1 plan
On 22/10/14 12:29, Dan Berindei wrote:
On Wed, Oct 22, 2014 at 1:32 PM, Galder Zamarreño
<galder(a)redhat.com
<mailto:galder@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