Commit graph

15 commits

Author SHA1 Message Date
Yuya Nishihara
16f2b82feb conflicts: change diff line marker to %%%%%%%
I feel the original -------/+++++++ pair is slightly confusing because
each half can be a separator by itself. I don't know what character other
than '-'/'+' is preferred, but let's pick '%' (for "mod") per @martinvonz
suggestion.
2022-09-20 15:26:29 +09:00
Martin von Zweigbergk
b84be06c08 conflicts: minimize diffs in materialized conflicts
One advantage of our conflict marker style (compared to the usual
3-way markers) is that they provide the user with the diff between the
base and one side so the user doesn't have to do that in their head
(which is how I use 3-way markers anyway). However, since we currently
always use the "first" side for the diff, that diff can be larger than
if we had picked the other side, which makes the marker style worse
than the usual 3-way markers. This has bothered me many times and it's
about time we fix it.
2022-07-12 07:46:45 -07:00
Martin von Zweigbergk
fc578a2dd7 conflicts: use insta in conflict tests 2022-07-12 07:46:45 -07:00
Martin von Zweigbergk
5c6f82ec7b tests: remove &UserSettings argument from TestRepo::init()
We don't even have any settings that affect the repo, so there's no
point in passing the settings. I think this was a leftover from before
we separated out the "workspace" concept; now we no longer create a
working-copy commit when we initialize a repo (we do that when we
attach the workspace).
2022-05-21 22:33:16 -07:00
Martin von Zweigbergk
4cf04f373e tests: move init_{repo,workspace} functions onto types
I tried to create a `TestRepo` and was surprised that I couldn't do
that by calling a function on it.
2022-05-21 22:33:16 -07:00
Martin von Zweigbergk
f16d2a237b backend: pass in path when reading/writing conflicts as well
We do it for all the other kinds of objects already. It's useful to
have the path for backends that store objects by path (we don't have
any such backends yet). I think the reason I didn't do it from the
beginning was because we had separate `RepoPath` types for files and
directories back then.
2022-03-31 10:23:33 -07:00
Martin von Zweigbergk
980e80618c tests: don't create workspaces in conflict tests 2022-02-05 15:39:03 -08:00
Martin von Zweigbergk
abedeeaacf tests: rename init_repo() to init_workspace()
Most tests need a repo but don't need a working copy. Let's have a
function for setting up a test repo. But first, let's free up the name
`init_repo()` by renaming it to `init_workspace()` (which is also more
accurate).
2022-02-05 13:02:19 -08:00
Martin von Zweigbergk
2c91af339b tests: extract variable for store in test_conflicts 2021-11-25 21:04:56 -08:00
Martin von Zweigbergk
ce094f64d5 testutils: make init_repo return a struct, including a Workspace
This is a fairly mechanical change; I'll do some minor cleanups in
later commits.
2021-11-25 21:04:56 -08:00
Martin von Zweigbergk
ea82340654 working_copy: preserve conflicts in the working copy until markers are removed
I realized only recently that we can try to parse conflict markers in
files and leave them as conflicted if they haven't changed. If they
have changed and some conflict markers have been removed, we can even
update the conflict with that partial resolution.

This change teaches the working copy to write conflicts to the working
copy. It used to expect that the caller had already updated the tree
by materializing conflicts. With this change, we also start parsing
the conflict markers and leave the conflicts unresolved in the working
copy if the conflict markers remain.

There are some cases that we don't handle yet. For example, we don't
even try to set the executable bit correctly when we write
conflicts. OTOH, we didn't do that even before this change.

We still never actually write conflicts to the working copy (outside
of tests) because we currently materialize conflicts in
`MutRepo::check_out()`. I'll change that next.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
cea6061f3d conflicts: add a function for parsing a materialized conflict
I initially made the working copy materialize conflicts in its
`check_out()` method. Then I changed it later (exactly a year ago, on
Halloween of 2020, actually) so that the working copy expected
conflicts to already have been materalized, which happens in
`MutableRepo::check_out`().

I think my reasoning then was that the file system cannot represent a
conflict. While it's true that the file system itself doesn't have
information to know whether a file represents a conflict, we can
record that ourselves. We already record whether a file is executable
or not and then preserve that if we're on a file system that isn't
able to record it. It's not that different to do the same for
conflicts if we're on a file system that doesn't understand conflicts
(i.e. all file systems).

The plan is to have the working copy remember whether a file
represents a conflict. When we check if it has changed, we parse the
file, including conflict markers, and recreate the conflict from
it. We should be able to do that losslessly (and we should adjust
formats to make it possible if we find cases where it's not).

Having the working copy preserve conflict states has several
advantages:

 * Because conflicts are not materialized in the working copy, you can
   rebase the conflicted commit and the working copy without causing
   more conflicts (that's currently a UX bug I run into every now and
   then).

 * If you don't change anything in the working copy, it will be
   unchanged compared to its parent, which means we'll automatically
   abandon it if you update away from it.

 * The user can choose to resolve only some of the conflicts in a file
   and squash those in, and it'll work they way you'd hope.

 * It should make it easier to implement support for external merge
   tools (#18) without having them treat the working copy differently.

This patch prepares for that work by adding support for parsing
materialized conflicts.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
9abee0096f conflicts: propagate errors from materialize_conflict()
All current callers pass in a buffer, so it should never fail, but the
function itself can't know that.
2021-10-24 23:02:00 -07:00
Martin von Zweigbergk
c0a26f7642 conflicts: work around rust-lang/rust#89716 2021-10-13 13:41:09 -07:00
Martin von Zweigbergk
b4b64eb7e5 conflicts: add tests of conflict materialization 2021-10-13 13:40:25 -07:00