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`.
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).
Since 57ba9a9409, if the automatic import from git results in some
abandoned commit, that information gets recorded in the `MutableRepo`,
but I forgot to add a call to rebase the descendants. That causes a
failed assertion at
81a8cfefcb/lib/src/transaction.rs (L86). This
patch add a test showing that failure.
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.
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.
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.
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.
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`).
These tests are very similar to the `jj restore -i` tests because `jj
edit -r $REV` is a specialized version of `jj restore -i --from $REV-
--to $REV` on non-merge commits.
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.
