2

I have a project with two branches:

     D---E branch1
    /
---A---C branch2

I want to apply commit E (but not D) on top of branch2.

I used git cherry-pick and git mergetool (with meld) for resolving conflicts. So far, so good.

However, suppose that the state of the file after commit C is

lineC1
<context C>
lineC2

and the change introduced by commit E is

-lineC1
+lineE1
<context E>
-lineC2
+lineE2

I would expect the result shown by default by the mergetool to be

lineE1
<context C>
lineE2

(i.e., lines E1 and E2 changed according to commit E but internal context kept from the current branch).

Instead, the mergetool (i.e., meld) by default shows:

lineC1
<context E>
lineC2

which really makes no sense.

How can I instruct git cherry-pick to keep the context from branch2 and only consider changes to the lines modified by commit E ?

Claudio
  • 10,614
  • 4
  • 31
  • 71

2 Answers2

3

There is generally no correct solution for merging, programs can only provide heuristic suggestions. If the suggestion is not what you need, you just need to edit it. I think meld should show you everything you need on the screen. And even if it does not you can use commands like git show <sha1>:<file> to display every existing version of your file for copy pasting. After you have edited the middle column in meld git will accept it as it is, regardless of the changes you made.

You might also want to try git config --global --add merge.conflictstyle diff3

In the next cherry-pick (or merge) the result of the conflict will be formatted a bit differently and with some luck more suitable for your case.

Uwe Geuder
  • 2,236
  • 1
  • 15
  • 21
  • Unfortunately, it doesn't work either. Thank you for your suggestion. – Claudio Sep 23 '13 at 10:05
  • 1
    You mean the diff3 style does not produce the automatic results you want? Well, that's not too surprising. As I wrote merging is a heuristic process and there are no guarantees that the result is what the user needs or that conflicts are detected correctly. You just have to accept the fact that you need to do the work manually if the heuristics are not good enough (well you could also start to improve git's merge heuristics...) Or did you mean you can't get it done even manually? – Uwe Geuder Sep 23 '13 at 12:43
0

You can try using a different merge strategy or different strategy options for the default strategy (recursive).

Take a look at git merge --help, section MERGE STRATEGIES.

I had a similar problem, although it did not involved that context difference of yours, and solved it using strategy option theirs (flag -Xtheirs)

volpato
  • 1,262
  • 17
  • 21