6 ms·

The thing about how merges are presented seems orthogonal to how to represent history. I also hate the default in git, but that is why I just use p4merge as a m

The thing about how merges are presented seems orthogonal to how to represent history. I also hate the default in git, but that is why I just use p4merge as a merge tool and get a proper 4-pane merge tool (left, right, common base, merged result) which shows everything needed to figure out why there is a conflict and how to resolve it. I don't understand why you need to switch out the VCS to fix that issue.

crote 7mo ago
Seconding the use of p4merge for easy-to-use three-pane merging. Just like most other issues with Git, if your merges are painful it's probably due to terrible native UX design - not due to anything conceptually wrong with Git.
- TacticalCoder 7mo ago
  Thirding it except I do it from Emacs. Three side-by-side pane with left / common ancestor / right and then below the merge result. By default it's not like that but then it's Emacs so anything is doable. I hacked some elisp code a great many years ago and I've been using it ever since. No matter the tool, merges should always be presented like that. It's the only presentation that makes sense.
  - MarsIronPI 7mo ago
    What tool do you use? Does Magit support it natively?
    - skydhash 7mo ago
      I think you need to enable 3 way merge by default in git's configuration, and both smerge (minor mode for solving conflicts) and ediff (major mode that encompass diff and patch) will pick it up. In the case of the latter you will have 4 panes, one for version A, another for version B, a third for the result C, and the last is the common ancestor of A and B. Addendum: I've since long disabled it. A and B changes are enough for me, especially as I rebase instead of merging.
  - jwr 7mo ago
    Isn't that what ediff does?
  - arikrahman 7mo ago
    The extensibility provided with Emacs Lisp has been helpful for hacking together my own Git/Jujutsu plugin. I tried to model it over lazygit/lazyjj although magit has been incredible to use and hard to depart from.
- roryokane 7mo ago
  Did you know that VS Code added support for the same four-pane view as p4merge years ago? I used p4merge as my merge tool for a long time, but I switched to VS Code when I discovered that, as VS Code’s syntax highlighting and text editing features are much better than p4merge’s. I also use the merge tool of JetBrains IDEs such as IntelliJ IDEA (https://www.jetbrains.com/help/idea/resolve-conflicts.html#resolve-conflicts-productivity-tips https://www.jetbrains.com/help/idea/resolve-conflicts.html#r...) when working in those IDEs. It uses a three-pane view, not a four-pane view, but there is a menu that allows you to easily open a comparison between any two of the four versions of the file in a new window, so I find it similarly efficient.
  - stbtrax 7mo ago
    how do you set that up? the default git tool version seems to be 3 pane
    - ramchip 7mo ago
      Looks like it's "Show Base" under the top-level "..." menu when working on a merge conflict https://github.com/microsoft/vscode/issues/155277#issuecomment-1283623303 https://github.com/microsoft/vscode/issues/155277#issuecomme...
galaxyLogic 7mo ago
Can it merge ordinary directories (in addition to git-bracnehs)?
roryokane 7mo ago
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 7mo 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 7mo 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 7mo ago
    Huge meld fan here, recommended by a professor about a year ago. Game changer
- psychoslave 7mo 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.
cxr 7mo ago
> I don't understand why you need to switch out the VCS to fix that issue. For some reason, when it comes to this subject, most people don't think about the problem as much as they think they've thought about it. I recently listened to an episode on a well-liked and respected podcast featuring a guest there to talk about version control systems—including their own new one they were there to promote—and what factors make their industry different from other subfields of software development, and why a new approach to version control was needed. They came across as thoughtful but exasperated with the status quo and brought up issues worthy of consideration while mostly sticking to high-level claims. But after something like a half hour or 45 minutes into the episode, as they were preparing to descend from the high level and get into the nitty gritty of their new VCS, they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over. For someone to be in that position and not have done even a cursory amount of research before embarking on a months (years) long project to design, implement, and then go on the talk circuit to present their VCS really highlighted that the familiar strain of NIH is still alive, even in the current era where it's become a norm for people to be downright resistant to writing a couple dozen lines of code themselves if there is no existing package to import from NPM/Cargo/PyPI/whatever that purports to solve the problem.
- hn_throwaway_99 7mo ago
  > they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over. It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why. I understand how commit snapshots and packfiles work, and the way delta compression works in packfiles might lead me to calling it "storing diffs" in a colloquial setting.
  - ghusbands 7mo ago
    A common misconception is that git works with diffs as a primary representation of patches, and that's the implied reading of "stores diffs". Yes, git uses diffs as an optimisation for storage but the underlying model is always that of storing whole trees (DAGs of trees, even), so someone talking about it storing diffs is missing something fundamental. Even renames are rederived regularly and not stored as such. However, context would matter and wasn't provided - without it, we're just guessing.
killerstorm 7mo ago
Yeah, also JetBrains IDEs like IntelliJ have very nice merge UI. Perhaps the value of doing it on SCM level is that it can remember what you did. Git has some not-so-nice edge cases.
hyttioaoa 7mo ago
I often find myself using the gitlens in vscode, to do something similar. I'd compare the working tree to the common base. Then I have the left pane with what's already in the base, the right pane is editable with the result in it. It's nice to have all the LSP features available too while editing.
eru 7mo ago
I agree! This is all good advice, but these days I just ask Claude for solving merge conflicts, and I can't remember it ever going wrong. Almost all merge conflicts I see in practice are fairly mechanically solved.
PunchyHamster 7mo ago
There isn't. Git plumbing is elastic enough that you could have way different workflows built on top of it and still have repo that is usable by other tools. Hell, git tools themselves offer a ton of customization, you can have both display and diff command different than the builtin very easily. Some of Git defaults and command syntax might suck but all of that can be fixed without touching repo format
commandersaki 7mo ago
Is there any FOSS tool that gives a 4-pane merge, or even 3-pane so long as the third pane would show the resulting change. That would be so handy.

crote 7mo ago

Seconding the use of p4merge for easy-to-use three-pane merging. Just like most other issues with Git, if your merges are painful it's probably due to terrible native UX design - not due to anything conceptually wrong with Git.

TacticalCoder 7mo ago
Thirding it except I do it from Emacs. Three side-by-side pane with left / common ancestor / right and then below the merge result. By default it's not like that but then it's Emacs so anything is doable. I hacked some elisp code a great many years ago and I've been using it ever since. No matter the tool, merges should always be presented like that. It's the only presentation that makes sense.
- MarsIronPI 7mo ago
  What tool do you use? Does Magit support it natively?
  - skydhash 7mo ago
    I think you need to enable 3 way merge by default in git's configuration, and both smerge (minor mode for solving conflicts) and ediff (major mode that encompass diff and patch) will pick it up. In the case of the latter you will have 4 panes, one for version A, another for version B, a third for the result C, and the last is the common ancestor of A and B. Addendum: I've since long disabled it. A and B changes are enough for me, especially as I rebase instead of merging.
- jwr 7mo ago
  Isn't that what ediff does?
- arikrahman 7mo ago
  The extensibility provided with Emacs Lisp has been helpful for hacking together my own Git/Jujutsu plugin. I tried to model it over lazygit/lazyjj although magit has been incredible to use and hard to depart from.
roryokane 7mo ago
Did you know that VS Code added support for the same four-pane view as p4merge years ago? I used p4merge as my merge tool for a long time, but I switched to VS Code when I discovered that, as VS Code’s syntax highlighting and text editing features are much better than p4merge’s. I also use the merge tool of JetBrains IDEs such as IntelliJ IDEA (https://www.jetbrains.com/help/idea/resolve-conflicts.html#resolve-conflicts-productivity-tips https://www.jetbrains.com/help/idea/resolve-conflicts.html#r...) when working in those IDEs. It uses a three-pane view, not a four-pane view, but there is a menu that allows you to easily open a comparison between any two of the four versions of the file in a new window, so I find it similarly efficient.
- stbtrax 7mo ago
  how do you set that up? the default git tool version seems to be 3 pane
  - ramchip 7mo ago
    Looks like it's "Show Base" under the top-level "..." menu when working on a merge conflict https://github.com/microsoft/vscode/issues/155277#issuecomment-1283623303 https://github.com/microsoft/vscode/issues/155277#issuecomme...

galaxyLogic 7mo ago

Can it merge ordinary directories (in addition to git-bracnehs)?

roryokane 7mo ago

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 7mo 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 7mo 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 7mo ago
  Huge meld fan here, recommended by a professor about a year ago. Game changer
psychoslave 7mo 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.

cxr 7mo ago

> I don't understand why you need to switch out the VCS to fix that issue. For some reason, when it comes to this subject, most people don't think about the problem as much as they think they've thought about it. I recently listened to an episode on a well-liked and respected podcast featuring a guest there to talk about version control systems—including their own new one they were there to promote—and what factors make their industry different from other subfields of software development, and why a new approach to version control was needed. They came across as thoughtful but exasperated with the status quo and brought up issues worthy of consideration while mostly sticking to high-level claims. But after something like a half hour or 45 minutes into the episode, as they were preparing to descend from the high level and get into the nitty gritty of their new VCS, they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over. For someone to be in that position and not have done even a cursory amount of research before embarking on a months (years) long project to design, implement, and then go on the talk circuit to present their VCS really highlighted that the familiar strain of NIH is still alive, even in the current era where it's become a norm for people to be downright resistant to writing a couple dozen lines of code themselves if there is no existing package to import from NPM/Cargo/PyPI/whatever that purports to solve the problem.

hn_throwaway_99 7mo ago
> they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over. It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why. I understand how commit snapshots and packfiles work, and the way delta compression works in packfiles might lead me to calling it "storing diffs" in a colloquial setting.
- ghusbands 7mo ago
  A common misconception is that git works with diffs as a primary representation of patches, and that's the implied reading of "stores diffs". Yes, git uses diffs as an optimisation for storage but the underlying model is always that of storing whole trees (DAGs of trees, even), so someone talking about it storing diffs is missing something fundamental. Even renames are rederived regularly and not stored as such. However, context would matter and wasn't provided - without it, we're just guessing.

killerstorm 7mo ago

Yeah, also JetBrains IDEs like IntelliJ have very nice merge UI. Perhaps the value of doing it on SCM level is that it can remember what you did. Git has some not-so-nice edge cases.

hyttioaoa 7mo ago

I often find myself using the gitlens in vscode, to do something similar. I'd compare the working tree to the common base. Then I have the left pane with what's already in the base, the right pane is editable with the result in it. It's nice to have all the LSP features available too while editing.

eru 7mo ago

I agree! This is all good advice, but these days I just ask Claude for solving merge conflicts, and I can't remember it ever going wrong. Almost all merge conflicts I see in practice are fairly mechanically solved.

PunchyHamster 7mo ago

There isn't. Git plumbing is elastic enough that you could have way different workflows built on top of it and still have repo that is usable by other tools. Hell, git tools themselves offer a ton of customization, you can have both display and diff command different than the builtin very easily. Some of Git defaults and command syntax might suck but all of that can be fixed without touching repo format

commandersaki 7mo ago

Is there any FOSS tool that gives a 4-pane merge, or even 3-pane so long as the third pane would show the resulting change. That would be so handy.