Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
The build script has a hierarchy of where the current git hash is
detected from: check $NIX_JJ_GIT_HASH, if that fails, ask jj, if that
fails, ask git.
If the build script is satisfied from a query higher up the priority
chain, there's no reason to instruct cargo to rereun and rebuild (and
relink) everything: for example if $NIX_JJ_GIT_HASH is set, there's no
need to check heads from either jj or git.
Although the build script takes effort to specify `jj log
--ignore-working-copy`, it would previously still get invalidated if jj
performed a snapshot (even if $NIX_JJ_GIT_HASH was set). This can be
fairly annoying when iterating on the test suite where each commit would
rebuild the CLI and by extension all of its tests.
1.90 was just released, so this seems reasonable, and it finally lets us
use let-chains. This includes all the clippy fixups too, and some small
changes suggested by Ilya.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This makes the `test_version` test failure when run at a merge commit
less confusing. The test could be fixed, but I'm not sure it's worth it,
as we probably don't want to release a version of `jj` compiled at a
merge commit.
Now, if `jj` is compiled at a merge commit, this would print:
```
$ jj --version
jj 0.31.0-fb10a78cb359d52c0eda518a42ab07f117909004-ff9c9d0d8b4e929843eb683709fc1717645796df-99e035c5054e71906d7293ed98b542a9055057ef
```
Admittedly, this is a bit of a quick hack, but I've been confused by
`jj --version` output when compiled at a merge commit enough times
to want it.
Prior art: https://github.com/jj-vcs/jj/pull/6311 and
https://github.com/jj-vcs/jj/pull/4033 both pick one commit id hash
to print. I think I prefer printing all of them, even if it will fail
tests at a merge commit. After this commit, the failure will at least
be easy to understand.
However, if we prefer to merge one of the others, I'm OK with that too.
I think `cargo publish` will currently fail because of the
`include_str!()` in `cli/src/commands/help.rs` pointing to
`../../../docs/`, i.e. outside of the crate directory. This patch
attempts to fix that creating a `cli/docs` symlink to `docs` and makes
the `include_str!` use that symlink. I hope the symlink will be
resolved at `cargo publish` time so it also works in the published
crate.
Because symlinks don't work well on Windows, I updated `cli/build.rs`
to include the original path (the one pointing outside the crate) if
`cli/docs` is not a symlink, so the regular build still should work on
Windows (but `cargo publish` won't).
Thanks to Yuya for proposing this solution.
When building this project with [Nix/Crane](https://github.com/ipetkov/crane/discussions/693), if the `jj-cli` dependency is specified in `Cargo.toml` as a git-based crate, `cargo vendor` splits this workspace up into sub-crate directories, which causes `cargo metadata` to fail when searching for relative deps in the workspace root.
This commit simply changes how the crate version is determined, using Cargo's built-in environment variable [`CARGO_PKG_VERSION`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
Since .git/HEAD is less frequently updated, this should avoid unneeded
recompilation on test-only changes. This only applies to colocated repo.
For non-colocated repo, maybe we can watch src/ and ../lib/src files?
This also adds $NIX_JJ_GIT_HASH to reflect hash changes (and to not rerun
if no .git nor .jj directory exists.)
Since the recent move of `builds.rs` to `cli/build.rs`, incremental
builds re-calcuate the version number and thus result in some
re-compilation and lots of re-linking.
Summary: In preparation for unifying all workspace dependencies across all
crates, let's go ahead and move the jj-cli crate into its own new directory.
This will also be a nicer and more uniform layout as we add new `jj-*` crates.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: Icf94e7ae5f290dc8e181215727b38ada
