3/22/2026 at 5:11:44 PM
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.by ulrikrasmussen
3/22/2026 at 6:09:26 PM
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...). 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
by roryokane
3/22/2026 at 6:26:19 PM
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.
by psychoslave
3/22/2026 at 6:41:25 PM
After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properlyby kungito
3/22/2026 at 6:57:44 PM
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.
by IgorPartola
3/22/2026 at 7:11:55 PM
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?
by marcellus23
3/22/2026 at 7:19:08 PM
> 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.
by IgorPartola
3/22/2026 at 7:22:23 PM
The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.by clktmr
3/22/2026 at 7:32:08 PM
Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts.As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits from the feature branch clogging up my main history. Nobody should ever need to revert main to that state and if I really really need to look at that particular code commit I can still find it in the feature branch history.
by IgorPartola
3/22/2026 at 7:14:56 PM
a better (more confusing) example:i have a branch and i want to merge that branch into main.
is ours the branch and main theirs? or is ours main, and the branch theirs?
by em-bee
3/22/2026 at 7:17:34 PM
I always checkout the branch I am merging something into. I was vaguely aware I could have main checked out but merge foo into bar but have never once done that.by IgorPartola
3/22/2026 at 7:43:50 PM
git checkout mybranch
git rebase main
by Sharlin
3/22/2026 at 7:58:15 PM
Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.by IgorPartola
3/22/2026 at 6:59:37 PM
iirc ours is always the commit the merge is starting from. the issue is that with a merge your current commit is the merging commit while with a rebase it is reversed.I suspect that this could be because the rebase command is implemented as a serie of merges/cherry-picks from the target branch.
by afiori
3/22/2026 at 7:49:06 PM
git checkout mybranch
git rebase main
by Sharlin
3/22/2026 at 8:04:03 PM
Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"by XorNot
3/22/2026 at 7:03:14 PM
[dead]by devnotes77
3/22/2026 at 7:29:51 PM
This is one of my pain points, and one time I googled and got the real answer (which is why it's such a pain point).That answer is "It depends on the context"
> The reason the "ours" and "theirs" notions get swapped around during rebase is that rebase works by doing a series of cherry-picks, into an anonymous branch (detached HEAD mode). The target branch is the anonymous branch, and the merge-from branch is your original (pre-rebase) branch: so "--ours" means the anonymous one rebase is building while "--theirs" means "our branch being rebased".[0]
[0] https://stackoverflow.com/questions/25576415/what-is-the-pre...
by awesome_dude
3/22/2026 at 6:19:44 PM
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.by ktm5j
3/22/2026 at 6:35:13 PM
I started using Meld years ago and continue to find people who've never heard of it. It's a pretty good tool.by newsoftheday
3/22/2026 at 7:28:51 PM
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!
by IshKebab
3/22/2026 at 7:13:09 PM
> 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.
by cxr
3/22/2026 at 5:20:27 PM
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.by crote
3/22/2026 at 6:03:29 PM
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#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.
by roryokane
3/22/2026 at 5:27:19 PM
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.
by TacticalCoder
3/22/2026 at 5:40:00 PM
What tool do you use? Does Magit support it natively?by MarsIronPI
3/22/2026 at 5:50:36 PM
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.
by skydhash
3/22/2026 at 5:49:03 PM
Isn't that what ediff does?by jwr