FR: Materialize files with conflict markers (or any files) in a way that can be parsed #3975
Comments
|
TODO: Check if there are problems with diffing non-empty files that don't end in a newline. If we do |
This happens for non-empty files only; the materialization code can handle files and hunks with 0 or more lines, but each line should terminate in a newline. This is an imperfect fix to jj-vcs#3968, a better fix is TODO; see jj-vcs#3975.
This happens for non-empty files only; the materialization code can handle files and hunks with 0 or more lines, but each line should terminate in a newline. This is an imperfect fix to jj-vcs#3968, a better fix is TODO; see jj-vcs#3975.
This happens for non-empty files only; the materialization code can handle files and hunks with 0 or more lines, but each line should terminate in a newline. This is an imperfect fix to jj-vcs#3968, a better fix is TODO; see jj-vcs#3975. This also implements FromIterator for Merge. I could split it into a separate commit, but then it'd have no uses.
This happens for non-empty files only; the materialization code can handle files and hunks with 0 or more lines, but each line should terminate in a newline. This is an imperfect fix to jj-vcs#3968, a better fix is TODO; see jj-vcs#3975. This also implements FromIterator for Merge. I could split it into a separate commit, but then it'd have no uses.
This happens for non-empty files only; the materialization code can handle files and hunks with 0 or more lines, but each line should terminate in a newline. This is an imperfect fix to jj-vcs#3968, a better fix is TODO; see jj-vcs#3975. This also implements FromIterator for Merge. I could split it into a separate commit, but then it'd have no uses.
This happens for non-empty files only; the materialization code can handle files and hunks with 0 or more lines, but each line should terminate in a newline. This is an imperfect fix to jj-vcs#3968, a better fix is TODO; see jj-vcs#3975. This also implements FromIterator for Merge. I could split it into a separate commit, but then it'd have no uses.
|
Just FYI, there's a long discussion with @yuja in #4088, which is leading to a different approach to this problem. The main limitation of the approach I suggested here is that The alternative we are discussing is to use longer conflict markers if the file with the conflict already contained some conflict marker-looking text before there were conflicts. The hope is that we can find out the necessary length of the conflict markers from the original conflict, and thus know when the file is resolved. See the discussion for more details. |
This is a tracking issue for this bug/FR. I'm promoting this discussion from #3968 (comment). I think I also have a plan now that could work, so I am posting an outline it here in case people have comments.
The alternative would be to declare that it is not a goal to be able to materialize any text file conflict, and show a materialization error instead. I was leaning towards this, but I think the following approach is simple enough to work.
Originally posted by @ilyagr in #3968 (comment)
This issue has been nerd-sniping me for a while; in addition to trailing newlines (Update: in non-empty files; we actually support files that are 0 or more lines, each ending with a newline), it's also a matter of encoding conflict markers inside files
TODO: find link. I remember discussing it with Martin recently in some PR, haven't found it yet. TLDR:
jjcurrently can't handle conflicts in out owntutorial.mdbecause ofhttps://github.com/martinvonz/jj/blob/638649b435795bbb991d840e9ad1750648d9b74a/docs/tutorial.md?plain=1#L284-L291
In the shortest term, I'll probably ignore both issues and just add newlines to the end of files.
However, I think I finally figured out a syntax that will work, will not require a complicated parser, and even be somewhat readable. Before computing conflicts (and only if a file is conflicted), we'd encode file contents as follows:
Fun, huh?
This relies on conflict markers having to start at the beginning of the line. If we ever have a notion of conflicts that happen in the middle of lines, we'd need a different syntax, of course. I think that would be nice, but also would probably need a whole different UI to be usable; I'm not sure it can be very usable in the terminal or as a text file.
The text was updated successfully, but these errors were encountered: