Advantages of a cherry-pick over merge?

[Python Prog]

Hi

We are having a debate internally among our company  about using git cherry-pick vs git-mere on propagating changes from one branch to another

We have been using cherry-pick in our team for few years and have automated this process using gerrit hooks and working great

Another team uses git merge to propagate changes using git hooks and is working great for them too

When we had a debate the team using git merge was arguing strongly about maintaining the common ancestor about a commit and its advantages and over a period of time using git-cherrypick will blow-up because of not maintaining the common ancestor which we thought wasn't the area where we have an issue or was never a problem when we used  git cherry-pick,I am not clear on what their point was?

I am looking for points in favour of cherry-pick with gerrit  vs gerrit merge,can some throw light in their expereince how using cherrypick was a very successful strategy for propagation ?

[Saša Živkov]

IMHO, this is not an either/or question. Both cherry-pick and merge are useful.

Example 1: Assuming we fixed several bugs in a release branch "stable-1.0" and want to include all these bug fixes in the master branch.

In that case we would merge stable-1.0 into master.

Example 2: Assume we fixed a bug in master and *afterwards* found out that the same bug is also present in stable-1.0.

In this case, we would cherry-pick the bugfix commit into the stable-1.0.

Merging master into stable-1.0 is not an option in this case as this would also bring all other changes done in master into the stable-1.0.

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Darragh Bailey]

Hi

Using git merge to propagate fixes from one branch to another sounds unusual if these are release branches and mainline because you'd end up including all changes and as a consequence any divergence is likely to result in a merge where code is added to resolve a conflict that does not appear on in the history of either side.

It sounds very git-flow-ish, so it probably depends on the branching strategy you'd prefer to use and how frequently code diverges (stable code base vs one under flux).

I'm impressed that it works automatically without needing lots of conflict resolution as the branches diverge.

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

--

[Jonathan Nieder]

> Using git merge to propagate fixes from one branch to another sounds unusual if these are release branches and mainline because you'd end up including all changes

This is exactly what the Gerrit project itself does (merging "forward" from older release branches to newer release branches and then to master), and it seems to work reasonably well.

Jonathan

чт, 30 авг. 2018 г. в 13:03, Darragh Bailey <daragh...@gmail.com>:

[Duft Markus]

To be more spcific, most projects (including Gerrit AFAIK) do merges like:

 

stable-1 > stable-2 > master

 

to get all fixes done on “older” release branches forward to newer releases up to master. But projects never do this the other way round:

 

master > stable-X

 

because that would destabilize the stable branch with potentially untested and API breaking changes.

 

Cheers,

Markus

SSI Schäfer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht für Zivilrechtssachen Graz

[Darragh Bailey]

On Fri, 31 Aug 2018 at 10:46, Duft Markus <Marku...@ssi-schaefer.com> wrote:

To be more spcific, most projects (including Gerrit AFAIK) do merges like:

 

stable-1 > stable-2 > master

Do you never hit conflicts in the merges with this approach? Because we used to try to use this (ala git-flow) where any release branch was merged back to master and there were frequent merge failures due to the code in the same area on master having changed and as well as the few cases of code added to the stable branch no longer being valid on master.

 

to get all fixes done on “older” release branches forward to newer releases up to master. But projects never do this the other way round:

 

master > stable-X

 

because that would destabilize the stable branch with potentially untested and API breaking changes.

 

Cheers,

Markus

--

[Jonathan Nieder]

Darragh Bailey wrote:

On Fri, 31 Aug 2018 at 10:46, Duft Markus <Marku...@ssi-schaefer.com> wrote:

To be more spcific, most projects (including Gerrit AFAIK) do merges like:

 

stable-1 > stable-2 > master

Do you never hit conflicts in the merges with this approach? Because we used to try to use this (ala git-flow) where any release branch was merged back to master and there were frequent merge failures due to the code in the same area on master having changed

This is not git-flow. git-flow is much more aggressive about branching (and I don't completely understand it, personally).

There are sometimes merge conflicts, which we manually resolve. Also occasionally (but rarely) CI notices that there was a semantic conflict between two changes that didn't conflict textually. But that's a good thing: it means we have some notice about how to integrate the changes well. We really do want all changes that were on the stable branch to go in master as well, so that people don't get a regression on upgrade.

Thanks,

Jonathan

[Matthias Sohn]

On Fri, Aug 31, 2018 at 4:01 PM Darragh Bailey <daragh...@gmail.com> wrote:

On Fri, 31 Aug 2018 at 10:46, Duft Markus <Marku...@ssi-schaefer.com> wrote:

To be more spcific, most projects (including Gerrit AFAIK) do merges like:

 

stable-1 > stable-2 > master

Do you never hit conflicts in the merges with this approach? Because we used to try to use this (ala git-flow) where any release branch was merged back to master and there were frequent merge failures due to the code in the same area on master having changed and as well as the few cases of code added to the stable branch no longer being valid on master.

we also do this for the projects I am working on. Sometimes there is a conflict when merging fixes from release branches

which need to be resolved. Frequency how often this happens depends on how often you need fixes on release branches

and how those patches interfere with new features being developed on master.

I think there is no difference if you cherry-pick the same patches from the same release branch.

You'll come across the same conflicts.

[Darragh Bailey]

On Fri, 31 Aug 2018 at 15:39, Matthias Sohn <matthi...@gmail.com> wrote:

On Fri, Aug 31, 2018 at 4:01 PM Darragh Bailey <daragh...@gmail.com> wrote:

On Fri, 31 Aug 2018 at 10:46, Duft Markus <Marku...@ssi-schaefer.com> wrote:

To be more spcific, most projects (including Gerrit AFAIK) do merges like:

 

stable-1 > stable-2 > master

Do you never hit conflicts in the merges with this approach? Because we used to try to use this (ala git-flow) where any release branch was merged back to master and there were frequent merge failures due to the code in the same area on master having changed and as well as the few cases of code added to the stable branch no longer being valid on master.

we also do this for the projects I am working on. Sometimes there is a conflict when merging fixes from release branches

which need to be resolved. Frequency how often this happens depends on how often you need fixes on release branches

and how those patches interfere with new features being developed on master.

I think there is no difference if you cherry-pick the same patches from the same release branch.

You'll come across the same conflicts.

I believe there is one, any changes made to resolve a merge conflict if they don't exist on either side of the merge are not obvious unless you remember to turn on the '-m' option when doing 'git log -p'. gitk will highlight it, presumably other tools spot it as well, but it can be a bit of a surprise to someone using the CLI with git log that it's not shown by default. Maybe there is an option to turn it on.

So I guess it depends on how frequent that occurs for you, we hit a few times when using the merge approach and then just stopped and switched to cherry-pick approach to avoid as such merges weren't nice to review. But I think its a preference depending on what's worked well for each particular use case.

 

[Jonathan Nieder]

> such merges weren't nice to review

Gerrit has some good features for reviewing merges: it shows the diff against a "naive" merge and lets you diff against the first parent as well.

For getting this kind of information in "git log", see https://crbug.com/git/12

Thanks,

Jonathan

пт, 31 авг. 2018 г. в 8:15, Darragh Bailey <daragh...@gmail.com>: