1

When I want to retrieve changes from master on a branch with:

git pull --rebase

and a modification has been done on master on a file I modified in my branch, an auto-merging is done on this file. The resulting file is a mixing of master modifications and branch modifications.

Why do I not have a file with some conflict-marked areas as I expected ?

EDIT Here is the problem description I encountered which is the origin of my question. On a branch B, I have a class C which implements the interface IC. I added locally a method to C. Another person on the same branch push some modifications. One of this modification was : add a method to IC and add an method implementation to C. This method is the method I previously added on my side. After the pull, Git has auto-merged the file C and 2 methods with the same signature existed in the class C. That's why I would like to forbid the auto-merge.

Ekans
  • 997
  • 1
  • 8
  • 16
  • 1
    http://stackoverflow.com/questions/5074452/git-how-to-force-merge-conflict-and-manual-merge-on-selected-file – Andrew C Nov 06 '15 at 15:33

1 Answers1

0

The reason for not getting such a file is because there are no conflicts. If there are no conflicts, everything can cleanly be merged. If some conflicts occur, git will warn you and either let you launch a merge tool or let you modify the conflicting lines manualy

EDIT If you want git to force to notify you of files it merged (i.e., to force conflicts), you should make a custom merge driver, see e.g. Git - how to force merge conflict and manual merge on selected file

EDIT With regards to your remark: In the "pull branch", there are two changes wrt master:

  1. delete block of code at line X
  2. Add block of code at line Y.

The expected behaviour is that IF the block of code at line X is unchanged in master, after merging the two changes take place: remove block of code at X and add block of code at Y.

This is exactly what git does! If you merge such a branch into master, afterwards the method will only occur once in the file, namely at the place where you moved it to

Where it might go wrong: if you have two branches: A and B. In A you move a method to line Y1, in B, you move the same method to line Y2. Git thinks: both branches share the "deletion", there is no conflict here. There are no conflicts wrt addition (since Y1 and Y2 are far apart)...

However, the use case you describe (method is only moved in one branch) will yield no problems.

Community
  • 1
  • 1
BartBog
  • 1,889
  • 14
  • 28
  • I don't understand why there is no conflict. In my case 2 persons changed the same file so only me can realize a merge. An auto-merge has no sense here. – Ekans Nov 06 '15 at 14:35
  • If they change different lines in this file, there might not be a conflict. For example if I change the first line of a file to "a" and you change the last line of that file to "b", the automatic merge would take the original file, and change the first and last line to "a", respectively "b" – BartBog Nov 06 '15 at 15:17
  • Ok I understand if the conflict is managed at line level. So can I have a "conflict manager" at file level? More generally how can I have a conflict in my use case? – Ekans Nov 06 '15 at 15:24
  • So you WANT git to generate a conflict whenever a file is modified by two different people? Just to be clear, conflicts are not really generated on line level. If two lines close to each other are modified, it will still give an error. – BartBog Nov 06 '15 at 15:50
  • Ok I accept your solution but I still don't understand why Git has this default behavior. For example, merging 2 Java files without reading the code it is impossible. What's happen if a method is moved inside the class from line X to line Y in master and in the branch (where the pull rebase is realized) the method is still at line X? Answer: the same method is defined 2 times after the pull rebase thanks to the auto-merging... How could that be an expected merge? I'm pretty new to Git. Maybe I use Git in the wrong way. – Ekans Nov 08 '15 at 22:12
  • Clarified my answer to reflect your concerns – BartBog Nov 09 '15 at 08:47
  • Thanks for your clarification. I added a clarification too. – Ekans Nov 12 '15 at 08:14