(new attempt in plain text) On Tue, Nov 7, 2023 at 3:49 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > Hi Elijah > > [I've cc'd Martin to see if he has anything to add about how "jj" > manages the issues around storing conflicts.] > > On 07/11/2023 08:16, Elijah Newren wrote: > > On Mon, Nov 6, 2023 at 1:26 PM Sandra Snan > > <sandra.snan@xxxxxxxxxxxxxxxxxx> wrote: > >> > >> Is this feature from jj also a good idea for git? > >> https://martinvonz.github.io/jj/v0.11.0/conflicts/ > > > > 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. > > One thing to think about if we ever want to implement this is what other > data we need to store along with the conflict trees to preserve the > context in which the conflict was created. For example the files that > are read by "git commit" when it commits a conflict resolution. For a > single cherry-pick/revert it would probably be fairly straight forward > to store CHERRY_PICK_HEAD/REVERT_HEAD and add it as a parent so it gets > transferred along with the conflicts. For a sequence of cherry-picks or > a rebase it is more complicated to preserve the context of the conflict. > Even "git merge" can create several files in addition to MERGE_HEAD > which are read when the conflict resolution is committed. Good point. We actually don't store any extra data in jj. The old per-path conflict model was prepared for having some label associated with each term of the conflict but we never actually used it. If we add such metadata, it would probably have to be something that makes sense even after pushing the conflict to another repo, so it probably shouldn't be commit ids, unless we made sure to also push those commits. Also note that if you `jj restore --from <commit with conflict>`, you can get a conflict into a commit that didn't have conflicts previously. Or if you already had conflicts in the destination commit, your root trees (the multiple root trees constituting the conflict) will now have conflicts that potentially were created by two completely unrelated operations, so you would kind of need different labels for different paths. https://github.com/martinvonz/jj/issues/1176 has some more discussion about this. > > 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, > > I think this is a really important point, while it can be useful to > share conflicts so they can be collaboratively resolved we don't want to > propagate them into "stable" or production branches. I wonder how 'jj' > handles this. Agreed. `jj git push` refuses to push commits with conflicts, because it's very unlikely that the remote will be able to make any sense of it. Our commit backend at Google does support conflicts, so users can check out each other's conflicted commits there (except that we haven't even started dogfooding yet). > > 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. > > As you point out there is a lot more to this than just being able to > store the conflict data in a commit - in many ways I think that is the > easiest part of the solution to sharing conflicts. Yes, I think it would be a very large project. Unlike jj, Git of course has to worry about backwards compatibility. For example, you would have to decide if your goal - even in the long term - is to make `git rebase` etc. not get interrupted due to conflicts.
