rebase is a oneliner op per branch you want to reapply whereas cherry picking requires to manually select the commits you want. Underneath in git guts it probably does the same.

I have to admit I barely had the occasion to want to click the GitHub UI button as except for simple documentation, reviewing code almost always require to fetch the branch and look at it in an IDE of sort for proper review. The documentation bit is actually even requiring local run since Markdown / Asciidoc and all tend to silently fail a syntax mistake.

On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus@redhat.com> wrote:


On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel@hibernate.org> wrote:

There is a difference between cherry picking and rebasing when it comes to reapply a work on top of a branch.

What is the difference? :-)

Do you dislike both equally compared to a merge (aka railroad nexus git history approach)?

Using github's "merge" button is pretty convenient imo, even though the history is not as nice as with a rebase (or cherry-pick, I miss the difference for now )



On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant@redhat.com> wrote:

Hi guys,

with the imminent release of 7.0.0.CR2 we are reaching the end of this 
release cycle. There have been a ton of improvements (maybe too many) 
and a lot of time has passed since the previous version (maybe to much).
Following up on my previous e-mail about future plans, here's a recap of 
a plan which I believe will allow us to move at a much quicker pace:

For the next minor releases I would like to suggest the following strategy:
- use a 3 month timebox where we strive to maintain master in an "always releasable" state
- complex feature work will need to happen onto dedicated feature branches, using the usual GitHub pull-request workflow
- only when a feature is complete (code, tests, docs, reviewed, CI-checked) it will be merged back into master
- if a feature is running late it will be postponed to the following minor release so as not to hinder other development

I am also going to suggest dropping the cherry-picking approach and going with git merge. In order to achieve this we need CI to be always in top form with 0 failures in master. This will allow merging a PR directly from GitHub's interface. We obviously need to trust our tools and our existing code base.

This is the plan for 7.1.0:

13 November 7.1.0.Alpha1
18 December 7.1.0.Beta1
15 January  7.1.0.CR1
30 January  7.1.0.Final


Tristan

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev