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.
