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(a)redhat.com> wrote:
On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev