The help text said you can `jj abandon; jj co @-` to go to the parent
commit (it it's an open commit), but `jj abandon` already takes you to
the parent.
Mercurial has these aliases, so it will be familiar for Mercurial
users. My only hesitation about adding these aliases is that we might
want the these names for something else in the future. You could
imagine `up` and `down` commands, for example. We still have a long
time before 1.0, so we have plenty of opportunity to make breaking
changes if we think of some other use for the names :)
It can be confusing that some commits (typically the working copy)
don't have a description. Let's show a placeholder text in such cases.
I chose the format to match the "(no email configured)" message we
already have.
This should help make e.g. `squash` discoverable for users who search
the help output for "amend". It should also help users discover the
builtin abbreviations like `st` (for `status`).
This adds a `--reversed` flag to `jj log` to show commits with later
commits further down. It works both with and without the graph.
Since the graph-drawing code is already independent of the
relationship between commits, it doesn't need any updating.
The default log output of showing all commits is not very useful when
contributing to an existing repo. Let's have it default to showing
commits not on any remote branch instead. I think that's the best we
can do since we don't have a configurable main branch yet, and we
don't even have per-repo configuration..
Closes#250.
`log -s/--summary` and `log --git` without `-p` don't do anything. I
also don't think it's very useful to pass these flags in an alias,
where you would then sometimes also pass `-p` to see the diff summary
in the output. We already have the `diff.format` config for that use
case. So let's make both of these flags imply `-p`.
I implemented it by making the `diff_format` variable an
`Option<DiffFormat>`, which is set iff we should show a patch. That
way we have the condition in one place, and the places we use it
cannot forget to check it.
Our support for aliases is very naively implemented; it assumes the
alias is the first argument in argv. It therefore fails to resolve
aliases after global arguments such as `--at-op`.
This patch fixes that by modifying the command defintion to have an
"external subcommand" in the list of available commands. That makes
`clap` give us the remainder of the arguments when it runs into an
unknown command. The first in the list will then be an alias or simply
an unknown command. Thanks to @epage for the suggestion on in
clap-rs/clap#3672.
With the new structure, it was easy to handle recursive alias
definitions, so I added support for that too.
Closes#292.
If a chain ends, we don't count the chain itself when calculating the
padding to use before text. This patch updates a few tests to use
multi-line descriptions so this is seen.
We actually already have a case of this bug `test_operations.rs`. I
noticed that when I added that test, but it didn't bother me enough to
fix it until now.
It's much easier to update the tests with `insta`.
It also presents you with the bad output including real newlines (a
diff, actually), so we can remove the `println!()` calls we had in
order to get readable output without escaped newlines.
With this patch, the order is this:
`$JJ_EDITOR` environement variable
`ui.editor` config
`$VISUAL` environement variable
`$EDITOR` environement variable
`pico`
That matches git, except that git falls back to an editor determined
at compile time (usually `vi`) instead of using `pico`.
As I said in 095fb9fef4, removing support for `~/.jjconfig` was an
experiment. I've heard from a few people (including in #233) that they
would prefer to have configs in the home directory. This patch
therefore restores that functionality, except I added a `.toml`
extension to the file to clarify the expected format to users and
editors.
After this patch, we still allow configs in `$XDG_CONFIG_HOME` (and
the other paths used by `dirs::config_dir()`), but we error out there
are config files in both that location and `~/.jjconfig.toml`.
It's cleaner to have all the calls in one place, and this structure
will also make it easier to return other errors from the `dispatch()`
function.
Note that there's still a call to `process::exit()` inside `clap` when
it fails to parse arguments.
We didn't have any testing of exit codes on failure, other than
checking that they were not 0. This patch changes that so we always
check. Since we have the special exit code 2 (set by `clap`) for
incorrect command line, I've replaced some testing of error messages
by testing of just the exit code.
As part of this, I also fixed `jj branch --allow-backwards` to
actually require `-r` (it didn't before because having a default value
means the argument is considered always provided).
The function only needs a mutable reference (it doesn't store an owned
value anywhere), and this will enable the caller (i.e. `main()`) to
use the `Ui` instance after control returns from `dispatch()`.
Tree merges can currently fail because of a failure to look up an
object, or because of a failure to read its contents. Both results in
`BackendError` because of a `impl From<std::io::Error> for
BackendError`. That's kind of correct in this case, but it wasn't
intentional (that impl was from `local_backend`), and we need to
making errors more specific for better error handling.
Apparently, I need to pass `--merge` option to use kdiff3 as a diff editor.
We could add `diff-editor-args` or extend `diff-editor` to a list of command
arguments, but we'll eventually add stock merge tools and the configuration
would look like:
[merge-tools.<name>]
program = ...
diff-args = [...]
edit-args = [...]
merge-args = [...]
I think I copied the name `write_tree()` from Git, but I find it quite
confusing, since it's not clear if it write a tree to the working copy
or reads the working copy and writes a tree to the store (it's the
former).
Used to produce a message like this:
```
thread 'main' panicked at 'failed to run diff editor: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/diff_edit.rs:136:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Now produces a message like this:
```
Error: Failed to edit diff: Error executing editor 'meld': No such file or directory (os error 2)
```
This adds `jj git push --change <revision>` which creates a branch
with a name based on the revision's change ID, and then pushes that
like with `--branch`. That can be useful so you don't have to manually
add the branch (and come up with a name for it). The created branch
behaves like any other branch, so it's possible to make it point to a
commit with a different change ID.
This is actually enough to fix#248, but I'll continue to work on
error handling for a while. I'd like to at least include the bad
object ID in this type of error messages.
Closes#248.
As requested by @talpr. I added this is a separate new command `jj git
remote list`. One could also imagine showing the listing when there is
no sub-command specified to `jj git remote`, but we don't have other
commands that behave that way yet.
Closes#243
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.
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.
This involved copying `UnresolvedHeadRepo::resolve()` into the CLI
crate (and modifying it a bit to print number of rebased commit),
which is unfortunate.
Certain commands should never rewrite commits, or they take care of
rebasing descendants themselves. We have an optimization in
`commands.rs` for those commands, so they skip the usual automatic
rebasing before committing the transaction. That's risky to have to
remember and `MutableRepo` already knows if any commits have been
rewritten (that wasn't the case before, in the Evolution-based
code). So let's just have `MutableRepo` do the check instead.
We very often expect success, and we sometimes want to get the stdout,
too. Let's add a convenience function for that. It saves a lot of
lines of code.
I had accidentally given the two positional arguments for `jj git
remote add` the same index. While fixing that, I realized that maybe
`clap` can infer the index based on the declaration order in the
struct. That does indeed seem to work, so I just removed all the
explicit `index` arguments instead.
The Derive API is easier to work with, less error-prone, and less
verbose, so it seems like a good improvement.
It was quite a bit of work to make the switch, and I'll be surprised
if I didn't make any mistakes in the translation. We unfortunately
don't have enough e2e tests to be very confident, so we'll have to fix
any problems as we discover them.
I've at least verified that the output of `jj debug completion --fish`
is unchanged, except for a few help texts I changed for different
reasons (consistency, clarity, avoiding redundancy).
It's useful for tests, scripts, and debugging to be able to use
specific config instead of the user's config. That's especially true
for our automated tests because they didn't have a place to read
config from on Windows before this patch (they read their config from
`{FOLDERID_RoamingAppData}`, which I don't think we can override in
tests).
I'm a little hesitant to do this because most tools I'm familiar with
have the config file directly in `~/`. It's also easier to describe
where to put the file if it doesn't vary across platforms. But we're
still early in the project, so let's try it and see if we get any
complaints.
I thought that `std::fs::canonicalize()` expanded "~", but it doesn't
seem to do that, which caused #131. Git seems to do the expansion
itself, so we probably also should. More importantly
`std::fs::canonicalize()` crashes when the file doesn't exist. The
manual expansion we do now does not.
Closes#131.
It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.
Closes#87.
The library crate shouldn't look up the user's `$HOME` directory
(maybe the library is used by a server process), so let's have the
caller pass it into the library crate instead.
I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.
Open commits are work-in-progress and `jj git push --branch <name>`
therefore errors out if the branch points to an open commit. However,
we don't do the same check if you run `jj git push` to push all
branches. This patch introduces such a check. Rather than error out,
we skip such branches instead.
I didn't make it check for open commits in ancestors. It's quite
unusual (at least in my workflow) to have a closed commit on top of an
open one. We can revisit if users get surprised by it.
It rarely makes sense to push commits with conflicts to a remote Git
repo (which is the only kind of remote we support so far), so let's
just error out instead of pushing a commit that others pulling from
the remote probably can't make sense of.
I've only added a simple test for the error case for now. `libgit2`
doesn't support pushing to a local repo, so it's harder to test the
success case. I suppose we'll have to have the regular `git` binary
running local servers in test eventually.
Closes#60.
We don't want variables from the developer's environment to affect
tests. You can make tests fail if you set `XDG_CONFIG_HOME` such that
`$XDG_CONFIG_HOME/jj/config.toml` exists and has e.g. an email
set. The fix is to not propagate any environment variables. Thanks for
@arxanas for pointing this out in #104.
We still need to set `$HOME` to prevent configs from being read from
the process owner's home directory (because that's what
`dirs::config_dir()` seems to fall back to if `$HOME` is not set). By
the way, I suspect we'd still not immune to configs from the
developers home directory on Windows, because that doesn't seem to be
controlled by `$HOME`.
When the backing Git repo is inside the workspace (typically directly
in `.git/`), let's point to it by a relative path so the whole
workspace can be moved without breaking the link.
Closes#72.
When using an internal Git repo (`jj init --git`), we make
`.jj/repo/store/git_target` point directly to the repo (which is bare
in that case). It makes sense to do the same when using an external
Git repo (`jj init --git-repo`), so the contents of
`.jj/repo/store/git_target` doesn't depend on whether the user
included the `.git/` on the CLI.
This patch introduces a `JJ_TIMESTAMP` environment variable that lets
us specify the timestamp to use in tests. It also updates the tests to
use it, which means we get to simplify the tests a lot now that that
the hashes are predictable.
We need the app (top-level `clap::Command`) in order to check if
e.g. `-R` was passed to `jj init` (for #101), and it seems cleaner to
pass the instance around than to re-create it when needed.
As pointed out by @arxanas in #88, the message saying something like
"At least 'bin/.DS_Store' was added back ..." is confusing especially
when the command you ran was just `jj untrack bin/.DS_Store`. Let's
clarify the message by saying exactly how many more files there are,
and specialize the message for when there is only one file. Also
update the message to say "would be added back" instead of "was added
back" since we don't actually change anything if some files would be
added back (since 4b91ad408c).
Should we even list all the files? I'm concerned that such a list
could be very long. On the other hand, it can also be annoying to have
to run `jj untrack some/dir/` and only be told about single file to
add to the ignore patterns every time.
When I recently changed the working copy to not have a commit ID
(e098c01935), I lost the check in `update_working_copy()` in
`commands.rs` that made us not print "Working copy now at: " if the
commit was unchanged. Now we always print, which is unnecessary and
confusing (it makes it seem like the commit changed even if it
didn't). Let's restore the check.
It can be useful in command prompts and scripts to be able to quickly
get e.g. the `jj status` output without spending time committing the
working copy (perhaps because some background process continuously
commits the working copy). One can already do that by passing
`--at-op=<operation ID>`, but then one needs to look up the operation
ID first. That is both extra work for the user/script and it means
there's an extra `jj op log` invocation to get the operation ID. Let's
have a global flag to make it easy and efficient to do.
When running in a working copy collocated with git's, we export the
working copy's commit's parent to git after every command. However, we
forgot to update our own record of git's HEAD. That means that on
subsequent imports from git, it'll look like the user had updated HEAD
using a git command. When we detect that, we trust that the user had
taken care of the changes in the working copy and we simply abandon
our old working copy commit. That led to the bug reported in $54,
where the second commit of a `jj split` got lost.
The fix is to also update our record of where git's HEAD is when we
tell git to update it.
Closes#54.
We no longer need the commit ID, so we shouldn't make the callers pass
it. This lets us simplify several tests, because they no longer to
create commits just to check out a tree in the working copy.
We used to use the value to detect races, but we use the tree ID and
the operation ID these days, so we don't need the commit ID.
By changing this, we can avoid creating some commit IDs in tests,
which is why I tackled this issue now.
There are only two callers of `LockedWorkingCopy::check_out()`. One is
in `commands.rs`. That caller already checks after taking the lock
that the old commit ID is as expected. The other caller is
`WorkingCopy::check_out()`. We can simply move the check to that level
since it's the only caller that cares now.
A few commands (`restore`, `diff`, and `untrack` so far) accept path
arguments, but they only support files. Let's make them work with
directories too.
It's harmless but potentially confusing to have multiple workspaces
with the same ID (it would mean that they always have the same
checkout). Let's just prevent it for now. We can add an override later
if people think of usecases for it.
When you run `jj co abc123` and that commit is already checked out, we
just print a message. The condition for that assumed that the checkout
existed, which it won't if you just ran `jj workspace forget`. Let's
avoid that crash, especially since `jj co` is an easy way to restore
the working copy if you had accidentally run `jj workspace forget`
(though `jj undo` is even easier).
It seems helpful to show in the log output which commit is checked out
in which workspace, so let's try that. I made it only show the
information if there are multiple checkouts for now.
In workspaces added after the initial one, the idea is to have
`.jj/repo` be a file whose contents is a path to the location of the
repo directory in some other workspace.
Because we record each workspace's checkout in the repo view, we can
-- unlike other VCSs -- let the user refer to any workspace's checkout
in revsets. This patch adds syntax for that, so you can show the
contents of the checkout in workspace "foo" with `jj show foo@`. That
won't automatically commit that workspace's working copy, however.
If the workspace is shared with a Git repo, we sometimes update Git's
HEAD ref. We should get the new checkout from the right workspace ID
when doing that (though I'm not sure we'll ever support sharing the
working copy with Git in a non-default workspace).
When importing Git HEAD, we already use the right workspace ID for the
new checkout, but the old checkout we abandon is always the default
workspace's. We should fix that even if we will never support sharing
a working copy with Git in a non-default workspace.
Before committing the working copy, we check if the working copy is
checked out to the commit we expect based on the repo's view. We
always use the default workspace's checkout, so we need to fix that.
We detect concurrent working copy changes by checking that the old
commit matches the repo's view. We should use the current workspace
when looking up the checkout in the view.
This adds a `jj move [--from <rev>] [--to <rev>] [-i]` command, which
lets you move some changes from one commit into another. `jj
squash/amend` is just a special case of this new command. Except for
that command's more specialized help text, instructions, etc., it
could be implemented as simply `jj move --to @-`.
I thought it was a bit unclear which part of the process was
interactive (it's only choosing parts of the diffs that is
interactive, not choosing destination or anything else).
We allow rebasing to a descendant, but that causes divergence because
the old commit remains visible. You could imagine making it work so
`jj rebase -r B -d D` on a linear chain "A-B-C-D" reorders it to
"A-C-D-B", but we don't do that yet, so let's just prevent the
divergence for now.
Now that we have the operation ID recorded in the working copy state,
we can tell if the working copy is stale. When it is, we update it to
the repo view's checkout.
When there are concurrent operations that want to update the working
copy, it's useful to know which operation was the last to successfully
update the working copy. That can help use decide how to resolve a
mismatch between the repo view's record and the working copy's
record. If we detect such a difference, we can look at the working
copy's operation ID to see if it was updated by an operation before or
after we loaded the repo.
If the working copy's record says that it was updated at operation A
and we have loaded the repo at operation B (after A), we know that the
working copy is stale, so we can automatically update it (or tell the
user to run some command to update it if we think that's more
user-friendly).
Conversely, if we have loaded the repo at operation A and the working
copy's record says that it was updated at operation B, we know that
there was some concurrent operation that updated it. We can then
decide to print a warning telling the user that we skipped updating
because of the conflict. We already have logic for not updating the
working copy if the repo is loaded at an earlier operation, but maybe
we can drop that if we record the operation in the working copy (as
this patch does).
When importing git HEAD in a working copy shared with git, we reset
the working copy to the new commit at the end. If we fail to reset the
working copy, we shouldn't commit the operation. This patch mostly
fixes that by locking the working copy while we commit the
operation. There's still a small risk that the operation commits and
we fail to write the working copy state, but there's not much we can
do about that (or it's not worth the effort anyway).
`WorkingCopy::check_out()` currently fails if the commit recorded on
disk has changed since it was last read. It fails with a "concurrent
checkout" error. That usually works well in practice, but one can
imagine cases where it's not correct. For an example where the current
behavior is wrong, consider this sequence of events:
1. Process A loads the repo and working copy.
2. Process B loads the repo at operation A. It has not loaded the
working copy yet.
3. Process A writes an operation and updates the working copy.
4. Process B loads the working copy and sees that it is checked out
to the commit process B set it to. We don't currently have any
checks that the working copy commit matches the view's checkout
(though I plan to add that).
5. Process B finishes its operation (which is now divergent with the
operation written by process A). It updates the working copy to
the checkout set in the repo view by process B. There's no data
loss here, but the behavior is surprising because we would usually
tell the user that we detected a concurrent update to the working
copy.
We should instead check that the working copy's commit on disk matches
what the previous repo view said, i.e. the view at the start of the
operation we just committed. This patch does that by having the caller
pass in the expected old commit ID.
I was surprised that we save the `TreeState` before
`LockedWorkingCopy::finish()`. That means that even if the caller
instead decides to discard the changes, some changes will already have
been written.
This patch changes the interface for making changes to the working
copy by replacing `write_tree()` and `untrack()` by a single
`start_mutation()` method. The two functions now live on the returned
`LockedWorkingCopy` object instead. That is more flexible because the
caller can make multiple changes while the working copy is locked. It
also helps us reduce the risk of buggy callers that read the commit ID
before taking the lock, because we can now make it accessible only on
`LockedWorkingCopy`.
`WorkingCopy::current_commit()` has been there from the beginning. It
has made less sense since we made the repo view keep track of the
current checkout. Let's remove it.
Before this patch, we got the old commit ID before we took the lock on
the working copy, which means we might unnecessarily create divergence
if another process just committed the working copy.
It turns out that the `--help` option is "global", so the description
we set on the top-level command already applies to subcommands (and
subsubcommands, etc.).
I wanted to have all the documentation available on the command line,
but that makes it harder to maintain and link to. Let's move it to
markdown instead. We may later be able to add some way of presenting
the markdown in the terminal (or maybe by first converting it to
reStructuredText).
Now that it's much easier to use a shared working copy between git and
jj, let's update the hint about how to set up a jj repo backed by the
git repo to use a shared working copy.
When initializing a jj repo in the same directory as its backing git
repo, add `.jj/` to `.git/info/exclude` so it doesn't show up to `git`
commands.
This is part of #44.
If the workspace's working copy is shared with the backing Git repo,
we now automatically update the checkout in jj to match Git's HEAD
when that has changed.
With this change, I think users should be able to run `jj init
--git-store=.` and then continue to use `git` commands and
non-mutating `jj` commands without issue.
This is part of issue #44.
This change makes commands automatically import git refs if they're
run in a workspace that shares its working copy with the underlying
git repo. The import is done in a separate transaction.
This is part of #44.
It's useful to know which commit is checked out in the underlying Git
repo (if there is one), so let's show that. This patch indicates that
commit with `HEAD@git` in the log output. It's probably not very
useful when the Git repo is "internal" (i.e. stored inside `.jj/`),
because then it's unlikely to change often. I therefore considered not
showing it when the Git repo is internal. However, it turned out that
`HEAD` points to a non-existent branch in the repo I use, so it won't
get imported anyway (by the function added in the previous patch). We
can always review this decision later.
This is part of #44.
If nothing changed in a transaction, it's rarely useful to commit it,
so let's avoid that. For example, if you run `jj git import` without
changing the anything in the Git repo, we now just print "Nothing
changed.".
Some time ago, I made commands not commit the working copy when run at
an old operation, but it seems that I forgot to make it not update the
working copy. If you run e.g. `jj --at-op=<some operation> rebase -d
<some commit>`, it doesn't make sense for that to update the working
copy.
`ReadonlyRepo::init_*()` currently calls `WorkingCopy::init()`. In
order to remove that dependency, this patch wraps the
`ReadonlyRepo::init_*()` functions in new `Workspace` functions. A
later patch will have those functions call `WorkspaceCopy::init()`.`
The `Repo` doesn't do anything with the `WorkingCopy` except keeping a
reference to it for its users to use. In fact, the entire lib crate
doesn't do antyhing with the `WorkingCopy`. It therefore seems simpler
to have the users of the crate manage the `WorkingCopy` instance. This
patch does that by letting `Workspace` own it. By not keeping an
instance in `Repo`, which is `Sync`, we can also drop the
`Arc<Mutex<>>` wrapping.
I left `Repo::working_copy()` for convenience for now, but now it
creates a new instance every time. It's only used in tests.
This further decoupling should help us add support for multiple
working copies (#13).
Having a concept of a "workspace" will be useful for adding support
for multiple workspaces (#13). You can think of the "workspace" as a
repo combined with a working copy. A workspace corresponds 1:1 with a
`.jj/` directory. It's pretty close to what other VCS simply call a
"repo", but I've ended up using the word "repo" for what Git calls a
"bare repo".
I was confused myself why the message was only printed by `jj co` and
not e.g. `jj undo`. That probably means that it should always be
printed (or never be printed).
Especially when working on a new-to-you project, it's common to end up
with unwanted files automatically tracked before you realize that you
should have added them to the `.gitignore`. Even after adding them to
the `.gitignore`, it's not trivial to make them no longer tracked (you
need to move them away, run e.g. `jj st`, then move them back). This
patch adds `jj untrack` to simplify that (without actually moving the
files).
Closes#14.
The diff-editing code shares the `TreeState` functionality with the
working-copy code. That means we can now let the user edit conflicts
without materializing them first. So now the user can do e.g. `jj edit
-r <some commit>` and resolve only some of the conflicts.
As @arxanas noted, it's hard to tell which commit is currently checked
out. Hopefully bright colors will help. Maybe setting a background
color would be even clearer, but that's harder to do because the
formatter doesn't support background colors yet.
