Cherry-pick via Gerrit UI fails due to conflict, but local git-cherry-pick works.

[everni...@hotmail.com]

Sorry I cannot paste the real code or any details here. I'd like to know if anyone has ever encountered a similar case.

We once allowed "merge content" for a repository so that it could solve some minor conflicts automatically. 

However later we found it did not always work as expected. The conflict could be solved but the file content was totally wrong sometimes.

So we just set "allow merge content" to false. "Submit type" is always "Merge if necessary".

After that we met with a new problem. They complain they encounter more conflicts than before.

And one of the cases seems unreasonable. When we cherry-pick a commit onto another branch, it fails and we cannot find any thing useful in Gerrit log.

Then we try to do it in the local repository, so that we can see what the conflict is. 

Make a new clone and checkout the target branch. The branch tip is the same and no new commit has been submitted.

Copy and paste the cherry-pick command "git fetch ssh://foo refs/changes/xx/yyyxx/1 && git cherry-pick FETCH_HEAD".

It works without any conflict. Push and review and submit. Everything goes well.

Is it because Jgit and Git work in different ways when it comes to the cherry-pick or merge thing?

It seems Jgit has more strict criteria for a conflict. 

Gerrit Version: 2.12.4

Git Version: 1.7.9

Thanks for your comments in advance.

[wangxia...@huawei.com]

Yes, we had it too on gerrit version 2.12.5. We choose the submit type as cherry pick.

So we wander it about the difference between jgit and git of implement of code conflicts. But no details more.

在 2016年11月6日星期日 UTC+8下午7:32:31，everni...@hotmail.com写道：

[everni...@hotmail.com]

Thanks for your reply.

If we set 'Allow content merges' back to true, Gerrit's cherry-pick will succeed. But we expect it to work when it's false.

I look through the gerrit issue list, and find Issue 3533. But no further comments since Aug 17. The last comment says 'Labels: Priority-3'.

[David Pursehouse]

On Mon, Nov 7, 2016 at 4:15 PM <everni...@hotmail.com> wrote:

Thanks for your reply.

If we set 'Allow content merges' back to true, Gerrit's cherry-pick will succeed. But we expect it to work when it's false.

When 'Allow content merges' is disabled, gerrit will not merge anything that requires a content merge.  In other words, if another commit was submitted that touches the same file(s) as your commit, the merge (or in this case the cherry-pick) will fail, even if there is not actually any conflict.

 

I look through the gerrit issue list, and find Issue 3533. But no further comments since Aug 17. The last comment says 'Labels: Priority-3'.

--
--
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.

[Saša Živkov]

On Mon, Nov 7, 2016 at 9:16 AM, David Pursehouse <david.pu...@gmail.com> wrote:

On Mon, Nov 7, 2016 at 4:15 PM <everni...@hotmail.com> wrote:

Thanks for your reply.

If we set 'Allow content merges' back to true, Gerrit's cherry-pick will succeed. But we expect it to work when it's false.

When 'Allow content merges' is disabled, gerrit will not merge anything that requires a content merge.

 

This is the behavior on submit...

In other words, if another commit was submitted that touches the same file(s) as your commit, the merge (or in this case the cherry-pick) will fail, even if there is not actually any conflict.

 ... but why should we enforce the same behavior on the cherry-pick action?

Cherry-pick is just preparing a new change which will again be subject to the "Allow content merges" policy

when it gets submitted.

 

I look through the gerrit issue list, and find Issue 3533. But no further comments since Aug 17. The last comment says 'Labels: Priority-3'.

--
--

To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.

[everni...@hotmail.com]

在 2016年11月7日星期一 UTC+8下午4:17:03，David Pursehouse写道：

On Mon, Nov 7, 2016 at 4:15 PM <everni...@hotmail.com> wrote:

Thanks for your reply.

If we set 'Allow content merges' back to true, Gerrit's cherry-pick will succeed. But we expect it to work when it's false.

When 'Allow content merges' is disabled, gerrit will not merge anything that requires a content merge.  In other words, if another commit was submitted that touches the same file(s) as your commit, the merge (or in this case the cherry-pick) will fail, even if there is not actually any conflict.

https://gerrit-review.googlesource.com/Documentation/cmd-create-project.html 

--use-content-merge

If enabled, Gerrit will try to perform a 3-way merge of text file content when a file has been modified by both the destination branch and the change being submitted. This option only takes effect if submit type is not FAST_FORWARD_ONLY. Disabled by default.

From this hint, I think if there is really any conflict, Gerrit should leave the conflict alone and raise the merge-conflict exception when "allow content merges" is false/disabled.

I don't think it's reasonable to fail "even if there is not actually any conflict". It would make the "allow content merges" policy quite odd.

As we have observed, most cherry-picks succeed both via Gerrit cherry-pick and via Git cherry-pick with "allow content merges" as false.