0

I have two branches, master and demand_prediction_module.

contents of master branch are:

enter image description here

contents of demand_prediction_module branch are:

enter image description here

when I try to merge demand_prediction_module into master I should get a conflict for the file dem_prediction_module.py. However,

enter image description here

After merging, the dem_prediction_module.py looks like below. The extra pass statement is deleted. but as you can see lines 4 to 7 are different in the 2 files above so why did they NOT give a merge conflict? I want to be able to choose which of the changes I want to keep.Preferrably the one from demand_prediction_module branch.

enter image description here

EDIT Below is the commit history.

enter image description here

I deliberately checkedout to demand_prediction_module branch then made a commit in order to see what happens during and after merging.

Jose_Peeterson
  • 145
  • 2
  • 8
  • Can you show the commit graph/history? I.e. Do both branches have commits the other misses? – user9794 Dec 07 '22 at 08:06
  • https://stackoverflow.com/a/58404579/4000607 – user9794 Dec 07 '22 at 08:08
  • 1
    You need to show 3 things to know if there should be a conflict. The 2 tips (which you provided there) _and_ how it looks like in the last common ancestor. Could you show that as well? You can get that commit with `git merge-base branch1 branch2`. – eftshift0 Dec 07 '22 at 08:09
  • Did you add the chart so we know what the last common ancestor is to answer my comment? That's not what we need, if that was your intent. What we need is how that block of code looks in the last common ancestor... which from looking at the chart, it should be `59eae302`. – eftshift0 Dec 07 '22 at 09:19

1 Answers1

0

It is showing in your merge command output. Merge made by 'ort' strategy. for this ort strategy. you can refer this link

ort This is the default merge strategy when pulling or merging one branch. This strategy can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this strategy can detect and handle merges involving renames. It does not make use of detected copies. The name for this algorithm is an acronym ("Ostensibly Recursive’s Twin") and came from the fact that it was written as a replacement for the previous default algorithm, recursive.

The ort strategy can take the following options:

ours This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected in the merge result. For a binary file, the entire contents are taken from our side.

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.

gautam thakur
  • 15
  • 4
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Dec 09 '22 at 19:21