1

Many questions where asked about Git not detecting rename after content change. I have a different problem: On common ancestor there is file f_rename.txt. On one branch (diverge) I rename(only, not content change) to f_rename_1.txt On other branch rename only to f_rename_2.txt

When merging the two branches, I get conflicts:

enter image description here

I can't understand this behaviour, even if I assume that Git doesn't detect the rename operation and f_rename_1 is assumed to be a new file, then why it marked as conflict ? conflict with what ?

Looking at stage files, it is clear that files where not modified(same SHA1): enter image description here

I was expecting to rename/rename as in Git conflict (rename/rename)

I'm not asking how to resolve the conflict !, but why Git behaves like this. I'm using Git '2.13.3.windows.1'

Thanks Boaz

Boaz Nahum
  • 1,049
  • 8
  • 9
  • If it wouldn't detect the rename, than it would not trigger a conflict. But since git knows that two renames happened, which are obviously in conflict with each other it generates a conflict. Why do you think the two renames are not in conflict? They tackle the same file in two impossible to combine ways. That's a conflict. – Nils_M Oct 18 '17 at 15:40
  • @Nils_M I understood my mistake, thanks to torek answer, I just still can't understand in case of large number of conflicts how can one analyzes and understand that this is rename/rename – Boaz Nahum Oct 19 '17 at 06:16

1 Answers1

1

The image you included in your question has git status output.

The CONFLICT (rename/rename): that you are expecting is printed by the git merge command.

The trace that this leaves behind in the index, which you are now seeing, is that the index has one stage-1 entry for the original name (with no stage-2 or stage-3 entry), one stage-2 entry for one of the new names (with no stage-1 or stage-3 entry), and one stage-3 entry for the other new name (with no stage-1 or stage-2 entry). The git status command prints that output for that kind of trace.

Look at the accepted answer to your linked question, which shows the same git status output. The both deleted line simply comes later, because the output is sorted by file names, and will-be-deleted starts with w which comes later.

torek
  • 448,244
  • 59
  • 642
  • 775
  • So @torek, in case of more than few conflicts, the developer should analyzes and detects these triple of conflicts and understand that it is rename/rename ? Is there a way to ease this analysis ? – Boaz Nahum Oct 19 '17 at 06:11
  • If you save the `CONFLICT ...` error-message output from the `git merge` command, you'll have the necessary information. It seems to me that Git really *should* write this to the index, making it retrievable for automation and for better `git status` output, since there are different kinds of what I call "high level" merge conflicts that become hard to distinguish without that data. (See https://stackoverflow.com/a/44360581/1256452) – torek Oct 19 '17 at 14:45