0

I am trying to complete a 3 way merge for a cherry picked commit, using Meld. However, I have difficulties understanding the directions in which changes flow between the 3 files shown by Meld. To give a better illustration, let's consider the following case:

On the master branch at commit 4e623e0, we have a tracked file, called test.c and it looks like this:

#include <stdio.h>

int main()
{
        printf("Hello world!\n");
        return 0;
}

We create branch 'other', and commit changes to test.c, so branch other is at commit 29771b0, and the test.c file looks like this:

#include <stdio.h>
#include "foo.h"
#include "headerx.h"
#include "headery.h"
#include "headerz.h"

int main()
{
        printf("Hello world!\n");
        if (x(2) > x(3))
                return -1; 
        else if (z(2) > z(3))
                return 44; 
        return 0;
}

Now we go back to branch 'master', and commit changes to test.c, so branch master is at commit 02fd8c8, and the test.c file looks like this:

include <stdio.h>
#include "foo.h"
#include "bar.h"

int main()
{
        printf("Hello world!\n");
        return bar_fun(2);
}

Finally, on the master branch, we attempt to do

git cherry-pick 29771b0
git mergetool

and the following window shows up: enter image description here

My question is:

  1. What sense does the marked arrow, pointing to the "LOCAL" file make?
  2. How can i turn off this "feature" (bug?)? It is rather annoying when merging large files, when Meld marks a big block of the "BASE" code and wants to push it into the "LOCAL" file.
  3. If it does make sense - why would I want to change, the "LOCAL" file? According to this SO post: Which version of the git file will be finally used: LOCAL, BASE or REMOTE?, the "LOCAL" pane should be open in read only mode. I have a rough understanding, of "LOCAL", "REMOTE", "BASE", and "MERGED" files, however the considered Meld option doesn't make sense to me.
maxnorbi
  • 36
  • 3
  • meld itself is not part of Git: it's a third-party add-on. Git only really cares that whatever the merge tool may do and be, it eventually write the correctly-merged file to the one in your work-tree. That apparently *used to* be called "merged" in meld (based on that other answer) but is now apparently just shown in the middle (again, *apparently:* I don't have or use meld). Apparently, your version of meld starts with the base file as the final result, and forces you to click arrows to bring in any changes from the local and/or remote files. – torek May 26 '20 at 14:17
  • @torek - I'm fine, with "bringing in" changes. What I don't understand is, "bringing out" changes. – maxnorbi May 26 '20 at 14:41
  • Again, I'm *guessing*, but: I bet the "bring out" changes part really means "after bringing in changes, change mind, and decide not to bring in changes". That is, clicking that left-pointing arrow will have no effect. It's probably a bug to even display that arrow at that point; it should only display after you've brought *in* the change. (Otherwise there should be right-pointing arrows in the middle as well.) – torek May 26 '20 at 14:55
  • Incidentally, most of this makes much more sense in a normal merge. A cherry-pick is a weird sort of merge in which the parent of the commit being picked is the `--theirs` (or REMOTE) commit and the current commit is the `--ours` (or LOCAL) commit. Both LOCAL and REMOTE should indeed be read-only (and in fact BASE should be as well, but perhaps it's combined BASE and MERGED internally here). – torek May 26 '20 at 14:57

1 Answers1

0

A cherry-pick is an interesting situation for a conflict. LOCAL (left pane) is code as it is on the revision where you are (in other words: HEAD). Now, local and REMOTE get a very special meaning. On a normal conflict on a merge, this interface (I assume, I don't know it) would show you the tip of the other branch on the right pane and the code as it is on (roughly) the last common ancestor at the center pane, where you get to edit the way the file will look like and stuff.

On a cherry-pick what those two sections show is a little different (actually, it's the same but cherry-pick is a different kind of merge). The REMOTE pane (right pane) will show you the code as it is on the revision you are cherry-picking (that's why you have the ifs as it is on other branch).... the middle pane is code as it appears on the parent of the revision you are cherry-picking (that's why it shows the code the way it looked on the first revision).

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • Unfortunately, I still don't understand the sense, of modifying the "LOCAL" file. After all, what should it be supposed to do? Amend the commit, at HEAD? – maxnorbi May 26 '20 at 14:15
  • You could do it if you wanted to... but _no_, not normally. The LOCAL file is _actually_ your starting point, even if the UI doesn't make it too obvious. Suppose you tried to backport a revision on a revision of the project that's _very_ old. What would code look like? What's the point of showing you the parent of the revision you are cherry-picking (center pane) and the result of the revision (right pane) if you have _no idea_ of what code actually looks like on the revision you should actually work? That won't fly. – eftshift0 May 26 '20 at 14:18