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).
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.
Somehow I had thought that setting `clap(required = true)` on a
list-type argument was not enough to convince clap to require at least
one occurrence, but it seems that it does. The `min_values = 1` I had
added to get it to work actually means that we accept multiple values
passed to a single argument (e.g. `jj rebase -d x y z`), which is not
what I had intended.
This addresses a TODO I had left in the code. In addition to the
reasons I mentioned in the TODO, config sources are also better
because they can be layered. I'm planning on using that for editor
configs, letting `$EDITOR` be a layer under the configs and
`$JJ_EDITOR` be a layer over (matching how `git` does it).
It's annoying especially for tests to not be able to append to a
config file without knowing the contents (as you have to do with
TOML). Let's read all files in a directory if `$JJ_CONFIG` points to a
directory. Mercurial does that for its `$HGRCPATH` variable.
I quite often want to move the changes to a particular file from one
commit to another. We already support that using `jj move -i`, but
that can be annoying to run because we don't have a TUI for it
(#48). Let's make it possible to do `jj move --from X --to Y <path>`.
It seems very unlikely that the user would want to untrack all paths
(that's still possible with `jj untrack .`, if they really want to,
and have added all their current paths to the `.gitignore`).
I'm adding this mostly because it's useful for testing. That's also
the reason it supports displaying conflicts. I didn't call it `cat`
like `hg cat` because I haven't found `hg cat` on multiple files
useful.
This removes the ui dependency from show_diff(), and clarifies that the
formatter argument is the output stream.
We might eventually trun DiffFormat into a struct, but it's an enum for
now.
With this change, we can eliminate (some of) the ui argument from diff
functions.
parse_file_path() can also be moved to WorkspaceCommandHelper, but I'm
yet to be sure how to reorganize it and matcher builder.
This prepares for the removal of the ui argument from diff functions. I
think it's a bit confusing that these functions take (ui, formatter)
parameters since both ui/formatter can be output stream.
Ui::format_file_path() will be moved to WorkspaceCommandHelper.
show_git_diff() doesn't need WorkspaceCommandHelper as of now, but I've
also changed its signature for consistency. If we add an option to specify
path formatting of git diff for example, we'll probably need the command
helper.
I've found it hard to read the `jj help` output because command
options are mixed with global options. This patch fixes that by
putting global options under a separate heading.
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.
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.
Closes#177.
This patch adds a very simple e2e test of having a working copy shared
with Git. The test initially failed on Windows. The symptom was that
the "master" branch did not get updated when we create a commit using
`jj`. That suggested that we didn't correctly detect that the working
copy was shared. After a lot of troubleshooting, I think I mostly
understand what we going on here (thanks to @arxanas for suggesting
https://github.com/mxschmitt/action-tmate). The path we get from
`git2::Repository::workdir()` seems to not be canonicalized in the
same way as `std::fs::canonicalize()` canonicalizes. Specifically, it
does not have the "\\?\" prefix we get from that function. I suppose
that's because libgit2 is a C library and canonicalizes the path using
some other system call.
"log -p | less" is the option I often use with hg/git to find interesting
bits from the changelog, and I think it's also valid with jj. Unlike
"hg log -p --stat", "jj log -p --summary" does not show both diff summary
and patch to reflect the internal structure. This behavoir is arguable and
may be changed later.
The logic of show_patch() is extracted from cmd_show().
We might want to split show_diff() into config/option handling part and
diff displayer function, but I'm not sure. Since some of the show_diff
functions depends on ui, we can't isolate show_diff() from the ui object
anyway.
let opts = parse_diff_option(ui, args); // map config/option to diff opts
show_diff(ui, formatter, opts, ...); // would be nice if ui could be removed
This parepares for "log --patch" option, where the formatter will be passed
as a function argument. Unlike diff/show, graphlog needs a temporary output
buffer per commit.
Successful commands should probably not write to stderr. If we later
add commands that e.g. print warnings to stderr, we'll want to cover
that explicitly in test.
