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.
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.
Sometimes it's useful to have an environment variable set for all
commands in a test. This patch lets you do that by adding environment
variables to the `TestEnvironment` itself. These will then be set on
all subsequent commands.
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().
This involved copying `UnresolvedHeadRepo::resolve()` into the CLI
crate (and modifying it a bit to print number of rebased commit),
which is unfortunate.
It's unusual for the current commit to have descendants, but it can
happen. In particular, it can easily happen when you run `jj new`. You
probably don't want to abandon it in those cases.
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.
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 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.
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.
The `trim_trailing_whitespace` config is not working well with
multi-line string literals. I've tried to work around
intellij-rust/intellij-rust#5368 twice and now I want to use the
`insta` crate so I'd need to find another workaround. Let's just
disable the config instead. I wouldn't be surprised if other editors
have similar bugs as IntelliJ.
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.
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.
The new `.editorconfig` tells editors to strip trailing whitespace,
but IntelliJ has a bug where it strips trailing whitespace even inside
multi-line strings. We can work around it in the cases we have because
they're regexes, so `[ ]` works as a space.
The `.jj/` directory contains information about two distinct parts:
the repo and the working copy. Most subdirectories are related to the
repo; only `.jj/working_copy/` is about the working copy. Let's move
the repo-related bits into a new `.jj/repo/` subdirectory. That makes
it clearer that they're related to the repo. It will probably also be
easier to manage when we have support for multiple workspaces backed
by a single repo.
I think this is just cleaner, and it gives us room to put other
store-related data in the `.jj/store/` directory. I may want to use
that place for writing the metadata we currently write in Git notes
(#7).
I considered even changing the message to "Checking out: <commit>" as
that's technically more correct (the message is printed when the
view's checkout is updated, i.e. before the working copy is
updated). However, I worried that users would find it confusing that
e.g. `jj close` would result in a "Checking out: " message, even
though that's what actually happens.
I remember adding that message a long time ago so the user has a trace
of working copy commit ids in the terminal output. They should be able
to get the same information from the operation log combined with
e.g. `jj st --at-op`.
Perhaps it makes more sense to display the working copy commit just
above the changes in the working copy commit, even though that means
that the order between the working copy commit and the parent becomes
the opposite of the order in `jj log`.
"{:?}" escapes `\` to `\\` for Windows paths. That breaks tests checking
paths without using "{:?}". Use PathBuf::display() in both commands and
tests to get consistent output.
This fixes test_init_local, test_init_git_internal, and
test_init_git_external on Windows.
I'm preparing to publish an early version before someone takes the
name(s) on crates.io. "jj" has been taken by a seemingly useless
project, but "jujube" and "jujube-lib" are still available, so let's
use those.
It's annoying to have to have the Git repo and Jujube repo in separate
directories. This commit adds `jj init --git`, which creates a new
Jujube repo with an empty, bare git repo in `.jj/git/`. Hopefully the
`jj git` subcommands will eventually provide enough functionality for
working with the Git repo that the user won't have to use Git commands
directly. If they still do, they can run them from inside `.jj/git/`,
or create a new worktree based on that bare repo.
The implementation is quite straight-forward. One thing to note is
that I made `.jj/store` support relative paths to the Git repo. That's
mostly so the Jujube repo can be moved around freely.
