6 ms·

Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" (https://git-scm.com/docs/git-config#Documentation/git-config

Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" (https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle https://git-scm.com/docs/git-config#Documentation/git-config...). If you do that, Git’s conflict markers show the base version as well: <<<<<<< left ||||||| base def calculate(x): a = x * 2 b = a + 1 return b ======= def calculate(x): a = x * 2 logger.debug(f"a={a}") b = a + 1 return b >>>>>>> right With this configuration, a developer reading the raw conflict markers could infer the same information provided by Manyana’s conflict markers: that the right side added the logging line.

ktm5j 6mo ago
I'm on my phone right now so I'm not going to dig too hard for this, but you can also configure a "merge tool" (or something like that) so you can use Meld or Kompare to make the process easier. This has helped me in a pinch to work out some confusing merge conflicts.
- newsoftheday 6mo ago
  I started using Meld years ago and continue to find people who've never heard of it. It's a pretty good tool.
- otherayden 6mo ago
  Huge meld fan here, recommended by a professor about a year ago. Game changer
psychoslave 6mo ago
That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabulary to convey the same idea.
- kungito 6mo ago
  After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly
  - IgorPartola 6mo ago
    Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.
    - marcellus23 6mo ago
      That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense. What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?
      - IgorPartola 6mo ago
        > What if I'm rebasing a branch onto another? Just checkout the branch you are merging/rebasing into before doing it. > Or if I'm applying a stash? The stash is in that case effectively a remote branch you are merging into your local codebase. ours is your local, theirs is the stash.
      - sheept 6mo ago
        "Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better without rebases and squash commits.
IshKebab 6mo ago
This is better but it still doesn't really help when the conflict is 1000 lines and one side changed one character and the other deleted the whole thing. That isn't theoretical - it happens quite regularly. What you really need is the ability to diff the base and "ours" or "theirs". I've found most different UIs can't do this. VSCode can, but it's difficult to get to. I haven't tried p4merge though - if it can do that I'm sold!
- pfg_ 6mo ago
  I tried p4merge a while ago and it didn't do it ubfortunately, still stuck copying the base and ours to seperate files and diffing them.
  - IshKebab 6mo ago
    So the way you can do it in VSCode is to open the conflict in their smart merge editor... Often it is actually smart enough to highlight the relevant change but if not each of the left/right editors has a button in its toolbar to diff it against the base. Not the easiest to access but better than copying/pasting (which is what I also used to do).
- fransje26 6mo ago
  If I understood your point correctly, I believe that Meld can do that. And then you get a windows as [1]. You can configure git to choose which version goes where. Something like: [mergetool "meld"] cmd = meld "$LOCAL" "$MERGED" "$REMOTE" --output "$MERGED" #cmd = meld "$LOCAL" "$BASE" "$REMOTE" --output "$MERGED" [1] https://linuxkamarada.com/files/2019/11/git-mergetool-meld-en.png https://linuxkamarada.com/files/2019/11/git-mergetool-meld-e...
tempodox 6mo ago
I still find this shit unreadable, even after years of practice.
- warmwaffles 6mo ago
  I've trained myself to avoid this entirely by avoiding changing lines unnecessarily. With LLMs, I also force them to stay concise and ONLY change what is absolutely necessary.
brunellus 6mo ago
roryokane thanks for this example. I tend to stick with git CLI and this was new to me.

ktm5j 6mo ago

I'm on my phone right now so I'm not going to dig too hard for this, but you can also configure a "merge tool" (or something like that) so you can use Meld or Kompare to make the process easier. This has helped me in a pinch to work out some confusing merge conflicts.

newsoftheday 6mo ago
I started using Meld years ago and continue to find people who've never heard of it. It's a pretty good tool.
otherayden 6mo ago
Huge meld fan here, recommended by a professor about a year ago. Game changer

psychoslave 6mo ago

That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabulary to convey the same idea.

kungito 6mo ago
After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly
- IgorPartola 6mo ago
  Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.
  - marcellus23 6mo ago
    That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense. What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?
    - IgorPartola 6mo ago
      > What if I'm rebasing a branch onto another? Just checkout the branch you are merging/rebasing into before doing it. > Or if I'm applying a stash? The stash is in that case effectively a remote branch you are merging into your local codebase. ours is your local, theirs is the stash.
    - sheept 6mo ago
      "Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better without rebases and squash commits.

IshKebab 6mo ago

This is better but it still doesn't really help when the conflict is 1000 lines and one side changed one character and the other deleted the whole thing. That isn't theoretical - it happens quite regularly. What you really need is the ability to diff the base and "ours" or "theirs". I've found most different UIs can't do this. VSCode can, but it's difficult to get to. I haven't tried p4merge though - if it can do that I'm sold!

pfg_ 6mo ago
I tried p4merge a while ago and it didn't do it ubfortunately, still stuck copying the base and ours to seperate files and diffing them.
- IshKebab 6mo ago
  So the way you can do it in VSCode is to open the conflict in their smart merge editor... Often it is actually smart enough to highlight the relevant change but if not each of the left/right editors has a button in its toolbar to diff it against the base. Not the easiest to access but better than copying/pasting (which is what I also used to do).
fransje26 6mo ago
If I understood your point correctly, I believe that Meld can do that. And then you get a windows as [1]. You can configure git to choose which version goes where. Something like: [mergetool "meld"] cmd = meld "$LOCAL" "$MERGED" "$REMOTE" --output "$MERGED" #cmd = meld "$LOCAL" "$BASE" "$REMOTE" --output "$MERGED" [1] https://linuxkamarada.com/files/2019/11/git-mergetool-meld-en.png https://linuxkamarada.com/files/2019/11/git-mergetool-meld-e...

tempodox 6mo ago

I still find this shit unreadable, even after years of practice.

warmwaffles 6mo ago
I've trained myself to avoid this entirely by avoiding changing lines unnecessarily. With LLMs, I also force them to stay concise and ONLY change what is absolutely necessary.

brunellus 6mo ago

roryokane thanks for this example. I tend to stick with git CLI and this was new to me.