2

Runnning merge command on different GIT versions we have different result:

Command is: git merge --no-ff origin/master_codeline

Results:

  • Version 2.1.4 -> Merge succeded
  • Version 1.7.1 -> The same merge command on the same commit return conflicts (CONFLICT (rename/add))

Now it would be easy to just update the GIT version on the OS but the 1.7.1 is the latest working version supported by our OS (Linux 2.6.34.10-0.2-xen SMP 2011-07-20 GNU/Linux, openSUSE 11.3 (x86_64) VERSION = 11.3) and we can't update the OS cause we have some constraint.

I was wondering if anyone ever experienced this kind of issues and if eventually there are way to workaround it, maybe tuning the GIT default merge options.

The conflicts output is:

CONFLICT (rename/add): Rename src/test/resources/env/env_branch2_jboss.prop->src/test/resources/env/dev2.prop in HEAD. src/test/resources/env/dev2.prop added in origin/master_codeline
Adding as src/test/resources/env/dev2.prop~origin_master_codeline instead
CONFLICT (rename/add): Rename src/test/resources/env/jboss.properties->src/test/resources/env/dev3.prop in HEAD. src/test/resources/env/dev3.prop added in origin/master_codeline
Adding as src/test/resources/env/dev3.prop~origin_master_codeline instead
Automatic merge failed; fix conflicts and then commit the result.

Unfortunately the VM where we are having these issues is our automation machine, and we run most of our merge operation on that VM.

ivoruJavaBoy
  • 1,307
  • 2
  • 19
  • 39
  • Did the conflict file(s) renamed on the side `origin/master_codeline`? – Marina Liu Apr 17 '18 at 09:52
  • Added in the question body the details about the conflicts – ivoruJavaBoy Apr 17 '18 at 10:03
  • The merge output on version 2.1.4 is simply `12 files changed, 1331 insertions(+), 177 deletions(-)` – ivoruJavaBoy Apr 17 '18 at 10:05
  • Do you really have the renames in your merged branches? Would switching off rename detection help? – max630 Apr 17 '18 at 11:13
  • I think that would make the trick, however i don't find way to make it work with 1.7.1, I cannot find any param to pass to the merge to skip renames.... the only thing that works till now it's suggested here https://stackoverflow.com/questions/6013261/disable-git-rename-detection in fact with the `-s resolve` the merge succeded, but as far I'm understanding i'm defining the merge strategy, not just skipping the renames, so I can impact the merge result also for other kind of conflicts, am i right? Any ideas? Thanks – ivoruJavaBoy Apr 17 '18 at 11:33
  • from the doc, the resolve strategy: resolve This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast. – ivoruJavaBoy Apr 17 '18 at 11:39

2 Answers2

0

You can use git status to check the detail merge conflict files. It's mainly caused some file show as deleted/added, and some file show as unmerged path.

You just need to use below commands to finish the renamed merge conflicts:

git add .
git commit
Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • Hi Marina, thanks for your reply but the issue is related to the merge operation and the rename policy as pointed out by max630. Of course i can add and commit the renamed files after the merge conflicts been raised, but this is not the case. I'm trying to reproduce the behavior of git 2.1.4 where the conflicts are not raised at all, not to find out how to resolve the conflicts :) – ivoruJavaBoy Apr 18 '18 at 08:21
  • As you can see in my comment, the conflicts are not raised if case i use the resolve strategy instead of the recursive strategy, this can be a solution, just it looks to me a bit "strong" to change all the merge strategy just because of the way git is managing the renaming during merge. Unfortunately the 1.7.1 merge seems not to have any parameter to simply skip the check on rename/add files, which instead is present from the version 1.7.4 – ivoruJavaBoy Apr 18 '18 at 08:25
  • Yes, my answer is just a workaround. It's mainly caused by the git versions to deal with rename files during merging. Since you can not update git version on that machine, so it needs additional operations for the renaming conflicts. Or you can add merge strategy -s resolve as you mentioned. – Marina Liu Apr 18 '18 at 08:39
0

You should try again with a 2.31+ Git version, which default to the new ORT merge strategy.

With Git 2.36 (Q2 2022), messages "ort" merge backend prepares while dealing with conflicted paths are clearer, and differentiates inner merges and outer merges.

See commit 4a3d86e (17 Feb 2022) by Elijah Newren (newren).
(Merged by Junio C Hamano -- gitster -- in commit b3db182, 25 Feb 2022)

merge-ort: make informational messages from recursive merges clearer

Signed-off-by: Elijah Newren

This is another simple change with a long explanation...

merge-recursive and merge-ort are both based on the same recursive idea: if there is more than one merge base, merge the merge bases (which may require first merging the merge bases of the merges bases, etc.).
The depth of the inner merge is recorded via a variable called "call_depth", which we'll bring up again later.
Naturally, the inner merges themselves can have conflicts and various messages generated about those files.

merge-recursive immediately prints to stdout as it goes, at the risk of printing multiple conflict notices for the same path separated far apart from each other with many intervenining conflict notices for other paths between them.
And this is true even if there are no inner merges involved.
An example of this was given in this thread and apparently caused some confusion:

CONFLICT (rename/add): Rename A->B in HEAD. B added in otherbranch
...dozens of conflicts for OTHER paths...
CONFLICT (content): Merge conflicts in B

In contrast, merge-ort collects messages and stores them by path so that it can print them grouped by path.
Thus, the same case handled by merge-ort would have output of the form:

CONFLICT (rename/add): Rename A->B in HEAD. B added in otherbranch
CONFLICT (content): Merge conflicts in B
...dozens of conflicts for OTHER paths...

This is generally helpful, but does make a separate bug more problematic.
In particular, while merge-recursive might report the following for a recursive merge:

Auto-merging dir.c
Auto-merging midx.c
CONFLICT (content): Merge conflict in midx.c
to-merging diff.c
to-merging dir.c
NFLICT (content): Merge conflict in dir.c

merge-ort would instead report:

Auto-merging diff.c
Auto-merging dir.c
Auto-merging dir.c
CONFLICT (content): Merge conflict in dir.c
Auto-merging midx.c
CONFLICT (content): Merge conflict in midx.c

The fact that messages for the same file are together is probably helpful in general, but with the indentation missing for the inner merge it unfortunately serves to confuse.
This probably would lead users to wonder:

  • Why is Git reporting that "dir.c" is being merged twice?
  • If midx.c has conflicts, why do I not see any when I open up the file and why are no conflicts shown in the index?

Fix this output confusion by changing the output to clearly differentiate the messages for outer merges from the ones for inner merges, changing the above output from merge-ort to:

Auto-merging diff.c
  From inner merge:  Auto-merging dir.c
Auto-merging dir.c
CONFLICT (content): Merge conflict in dir.c
  From inner merge:  Auto-merging midx.c
  From inner merge:  CONFLICT (content): Merge conflict in midx.c

(Note: the number of spaces after the 'From inner merge:' is 2*call_depth).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250