When committing the working copy, we try to not visit ignored
directories (as e.g. `target/` often is), but we need to visit it if
there are already tracked files in it. I initially missed that in
c1060610bd and then fixed it in a028f33e3b. The fix works by
checking if the next path after the ignored path is inside the ignore
path (viewed as a directory). However, I forgot to handle the case
where there are no paths at all after the ignored path. So, for
example, if the `target/` directory should be ignored and it there
were no tracked paths after `target/` in alphabetical order, we would
still visit the directory. That's why the bug reproduced in the
`git-branchless` repo but not in the `jj` repo (because there are
files under `testing/` and `tests/` here).
Closes#247.
This adds a `jj sparse` command with options to list and manage the
set of paths to include in the working copy. It only supports includes
(postive matches) for now.
I'm not sure "sparse" is the best name for the feature. Perhaps it
would make sense as a subcommand under `jj workspace` - maybe `jj
workspace track`? However, there's also `jj untrack` for removing a
file from the working copy and leaving it in the working copy. I'm
happy to hear suggestions, or we can get back to the naming later.
Most commands that are going to make changes to the working copy want
to share some logic for detecting concurrent changes, so let's extract
that to a function.
This patch makes room for sparse patterns in the `TreeState` proto
message. We also start setting that value to a list of just the
pattern `.` when we create new working copies. Old working copies
without the sparse patterns are also interpreted as having that single
pattern. Note that this absence of sparse patterns is different from a
present list of no patterns. The latter is a valid state and means
that no paths are included in the sparse checkout.
This adds a matcher that takes two input matchers and creates a new
matcher from them. The composite matcher matches paths matched by the
first matcher but not matched by the second matcher. I plan to use
this for sparse checkouts. They'll also be useful if we add support
for negative patterns to filter e.g. `jj files` by.
Knowing that a matchers matches everything recursively from a certain
directory is useful for various optimizations. For example, it lets
you avoid visiting a directory if you're using a matcher with a
negative condition (so you return what does *not* match).
If not set, then `cargo run` produces this error:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: fake-diff-editor, fake-editor, jj
```
It's useful for testing to be able to specify some operation that's
not the latest one.
I didn't update the changelog because this feature is mostly for
testing.
When loading a repo, `@` means the latest operation, possibly even
merging any concurrent operations. After loading a repo, `@` means the
operation the repo was loaded at. For example, when running `jj
--at-op=abc123 undo -o @`, `@` will undo operation `abc123`. This
patch therefore makes `resolve_single_op()` more generic by letting
the caller pass in what `@` should resolve to. I also added version of
the function on `WorkspaceCommandHelper` for convenience.
The function doesn't make anything simpler for us, and I think it will
be easier to implement simple "opsets" (like "revsets" for operations)
if we work directly with the operation objects (instead of repo
objects).
Otherwise, Git tries to resolve the conflict textually and introduces conflict markers, which make `cargo` unable to process the file (and therefore unable to resolve the conflicts automatically, such as with `cargo update`).
I originally made the operation argument a named argument
(`--operation`) to allow for a change ID to be passed as a positional
argument, matching e.g. `hg revert -r <rev> <path>`. However, even if
we add support for undoing changes only to certain change IDs, it's
going to be done much less frequently than full undo/restore. We can
therefore make that a named argument if we ever add it.
The `DescendantRebaser` keeps a map of branches from the source
commit, so it gets efficient lookup of branches to update when a
commit has been rebased. This map was not kept up to date as we
rebased. That could lead to branches getting left on hidden
intermediate commits. Specifically, if a commit with a branch was
rewritten by some command, and an ancestor of it was also rewritten,
then we'd only update the branch only the first step and not update it
again when rebasing onto the rewritten ancestor.
I noticed earlier today that branches get lost (stuck on a hidden
commit) when you move part of a change to an ancestor. This patch adds
tests for both of those cases, showing the bug. There's no special
logic for this case in the CLI crate, so we should be able to test it
in the library crate instead, but since I have already written the
tests, maybe we can keep them.
When a directory is missing in one merge input (base or one side), we
would consider that a merge conflict. This patch changes that so we
instead merge trees by treating the missing tree as empty.
This patch sets up an additional CI strategy running tests on 1.58, to
make sure we don't accidentally use newer features. I've only made it
run on one platform (Linux) to avoid wasting resources. There's of
course a small risk that we start depending on platform-specific APIs
from newer versions.
