Re: first-class conflicts?

On Mon, Nov 6, 2023 at 1:26 PM Sandra Snan <sandra.snan@idiomdrottning.org> wrote:

Martin talked about this and other features at Git Merge 2022, a little over a year ago. I talked to him in more depth about these while there. I personally think he has some really interesting features here, though at the time, I thought that the additional object type might be too much to ask for in a Git change, and it was an intrinsic part of the implementation back then.

Martin also gave us an update at the 2023 Git Contributors summit, and in particular noted a significant implementation change to not have per-file storage of conflicts, but rather storing at the commit level the multiple conflicting trees involved. That model might be something we could implement in Git. And if we did, it'd solve various issues such as people wanting to be able to stash conflicts, or wanting to be able to partially resolve conflicts and fix it up later, or be able to collaboratively resolve conflicts without having everyone have access to the same checkout.

But we'd also have to be careful and think through usecases, including in the surrounding community. People would probably want to ensure that e.g. "Protected" or "Integration" branches don't get accept fetches or pushes of conflicted commits, git status would probably need some special warnings or notices, git checkout would probably benefit from additional warnings/notices checks for those cases, git log should probably display conflicted commits differently, we'd need to add special handling for higher order conflicts (e.g. a merge with conflicts is itself involved in a merge) probably similar to what jj has done, and audit a lot of other code paths to see what would be needed.

I think it'd be really interesting to at least investigate, but it'd also be a lot of work, and I already have several other things I've been wanting to get back to for over a year and haven't succeeded in generating more time for Git.

Anyway, just my $0.02. Elijah