You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I generally find that most conflict resolution programs are too heavy-weight or get in the way, so I usually just open the conflicts in vim and handle them that way. jj has a novel way of describing conflicts, which I really want to like, but after trying it out for a while it causes a few problems for me.
E.g. in a (completely contrived) conflict like this:
<<<<<<<
+++++++
when shouldSave do
saveFile (Just FollowSymlinks) filePath
print "Saved!"
%%%%%%%
when shouldSave do
- saveFile Nothing filePath
+ atomicSaveFile Nothing filePath
print "Saved!"
>>>>>>>
It seems that the %%%%%% portion, which is diffed from the base, inserts indentation at the beginning of all the lines, this means that even if I remove all the + and -'s I still need to fix the indentation of the block to match the surrounding code, which is especially important/annoying in white-space sensitive languages.
I have a really hard time figuring out which changes are from which revision
Describe the solution you'd like
I'd love the option to have jj insert labelled conflict markers similar to Git's traditional 3-way diff and just include each of the revisions as-is without the clever diffing. I know jj can have an arbitrary number of parents, but that's fine, just insert the code from each parent revision without any diffing :)
<<<<<<< cro -- MERGE BASE
when shouldSave do
saveFile Nothing filePath
print "Saved!"
+++++++ lsk -- Make save follow symlinks
when shouldSave do
saveFile (Just FollowSymlinks) filePath
print "Saved!"
+++++++ soq -- Make saving atomic
when shouldSave do
atomicSaveFile Nothing filePath
print "Saved!"
>>>>>>>
I'd of course be fine with this being a configuration option, since I'm sure some folks are happy with the current behaviour.
Describe alternatives you've considered
Conflict resolution is difficult, I'm sure there are dozens of variations which could also solve this issue, but I think something close to git's 3-way diff makes sense here :)
Thanks for all the work you've put in, it's refreshing to see a new take in this space 😄
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I generally find that most conflict resolution programs are too heavy-weight or get in the way, so I usually just open the conflicts in vim and handle them that way.
jj
has a novel way of describing conflicts, which I really want to like, but after trying it out for a while it causes a few problems for me.E.g. in a (completely contrived) conflict like this:
It seems that the
%%%%%%
portion, which is diffed from the base, inserts indentation at the beginning of all the lines, this means that even if I remove all the+
and-
's I still need to fix the indentation of the block to match the surrounding code, which is especially important/annoying in white-space sensitive languages.I have a really hard time figuring out which changes are from which revision
Describe the solution you'd like
I'd love the option to have jj insert labelled conflict markers similar to Git's traditional 3-way diff and just include each of the revisions as-is without the clever diffing. I know jj can have an arbitrary number of parents, but that's fine, just insert the code from each parent revision without any diffing :)
I'd of course be fine with this being a configuration option, since I'm sure some folks are happy with the current behaviour.
Describe alternatives you've considered
Conflict resolution is difficult, I'm sure there are dozens of variations which could also solve this issue, but I think something close to git's 3-way diff makes sense here :)
Thanks for all the work you've put in, it's refreshing to see a new take in this space 😄
The text was updated successfully, but these errors were encountered: