My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2734: Scary red "Cannot Merge" message along with "Merge Change" button
8 people starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----


Sign in to add a comment
 
Reported by b...@demeterr.com, Jun 25, 2014
************************************************************
***** NOTE: THIS BUG TRACKER IS FOR GERRIT CODE REVIEW *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, INTERNAL *****
***** ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.    *****
***** THOSE ISSUE BELONG IN DIFFERENT ISSUE TRACKERS!  *****
************************************************************

Affected Version: 2.9 RC1

What steps will reproduce the problem?
1. Submit a CR that merges to master using Recursive Merge strategy (using git CLI)
2. Observe "Cannot Merge"
3. Refresh page - "Merge Change" button now appears.

What is the expected output? What do you see instead?

We are getting conflicting feedback from the Gerrit UI about the merge-ability of a CR (see attached screenshot)

Please provide any additional information below.

cannot_merge_psych.png
14.2 KB   View   Download
Jun 25, 2014
#1 dborowitz@google.com
That "cannot merge" is saying, "you can click 'merge' if you really want, but if you do, expect a merge conflict."

Unfortunately there are several error cases where the check to populate that flag will fail but the merge might actually succeed. If merging actually succeeds despite the warning, and you can reliably reproduce it (e.g. push the same change contents multiple times and observe the same result), that's probably a bug.

You also might try a more recent RC as I believe some bugs around this feature were fixed in the 2.9 release cycle.
Jun 26, 2014
Project Member #2 edwin.ke...@gmail.com
It is intended that you can still click on the 'Merge Change'/'Submit' button when there are merge conflicts. This is to support the following workflow:

1. Have a series of (many) open changes that depend on each other.
2. The review takes time, but in the end all changes get approved.
3. Now a lot of those changes have merge conflicts because the head of the destination branch has moved on.
4. Rebasing the whole series and do conflict resolution for every change and then go through the review once more to get them all approved again may be too much overhead in this case.
5. Instead: create a merge commit on top of the change series that merges the change series into the destination branch. In this commit resolve all conflicts at once. Now you can submit all changes top down, starting with the merge commit. They will be all in the state 'Submitted, Merge Pending' until you reach the bottom change. Now the submit will go through since Gerrit merges all changes at once and the conflicts are resolved by the merge commit.

This workflow is only possible if the 'Merge Change'/'Submit' button is available even if there are Merge Conflicts. And yes, we do have people that work this way with Gerrit.
Nov 12, 2014
#3 jrobert...@gmail.com
My organization uses the workflow described in comment #2. We use topic branches and generally do not rebase them once created, then create merge commits to bring the topics back into the main branch.

This means that many changes have the status "Merge Conflict" on the overview page and the scary red "Cannot Merge" on the change page. It is confusing and distressing our users.

Is there a plan to support this workflow better? Even just an option to hide these warnings would be helpful.
Feb 1, 2015
#4 tsuna...@gmail.com
It seems that the definition of "merge conflict" used by Gerrit is "two changes are editing the same file".  I'm making a guess, I didn't actually look at the source code in Gerrit, but that's the impression I have from my experience seeing this message a lot.

Every day I have lots of commits that are marked as "Merge Conflict" / "Cannot Merge" by Gerrit, but most of the time the changes integrate just fine.  FWIW, I use the strategy "Rebase if Necessary" and we're on the newly released Gerrit 2.10 (but this issue started in 2.9.x).

Most of the users in our organization have learned to ignore this "advice" from Gerrit's UI.  If the change really fails to merge then it'll be dealt with manually (i.e. someone rebases the change and fixes the conflicts and sends another patch set to Gerrit).
Apr 16, 2015
#5 sschuberth
@4 You're right, Gerrit's default understanding of a "merge conflict" is a "path conflict", which is different from what "git merge" names a "merge conflict".

Unless "Automatically resolve conflicts" is "TRUE" in the project's settings, "the merge will only succeed if there is no path conflict". So even if there is no content conflict a "merge conflict" would be displayed. That's probably what confuses the OP.

This is why I personally always recommend to enable "Automatically resolve conflicts" to let Gerrit try to do a content merge. The wording of that option also is misleading: No real (i.e. content) conflict is being automatically resolved. It really just is about Gerrit trying "to do a content merge when a path conflict occurs".

[1] https://gerrit-documentation.storage.googleapis.com/Documentation/2.11/project-configuration.html#submit_type
Apr 17, 2015
#6 marc.her...@gmail.com
> You're right, Gerrit's default understanding of a "merge conflict" is a "path conflict", which is different from what "git merge" names a "merge conflict".
> ...
> The wording of that option also is misleading: No real (i.e. content) conflict is being automatically resolved.

Tempting excuse: http://martinfowler.com/bliki/TwoHardThings.html

However this excuse does not really work here: Gerrit should simply never re-use git terms and apply them to something different; utterly confusing.

"path conflict" is short yet an excellent clarification. Use it generously in the interface and consider most of this bug fixed.

Apr 17, 2015
#7 sschuberth
FYI, I tried to improve the wording in
https://gerrit-review.googlesource.com/67166.
Sign in to add a comment

Powered by Google Project Hosting