Users now have the option of installing from source or directly
installing a binary.
I also corrected some text that effectively said that installing a Nix
flake is not installing from source, but I think it actually does
install from source.
I've found it hard to figure out which actions need which
permissions. GitHub doesn't seem to even document what the permissions
mean. So let's just give Clippy full access.
The new code scanner is complaining that actions have permissions to
do too much. It wasn't obvious to me what permissions the jobs need,
but let's see how this works.
I forgot to bump the version to 0.3.2 before tagging and releasing it,
so the released 0.3.2 has version number 0.3.1 in the source code and
(therefore) reported from `jj --version`. I'm therefore bumping it
from 0.3.1 to 0.3.3 now, so there can be a matching 0.3.3 release.
My attempt at using rust-build/rust-build.action for release builds
(from bf21e65c5d) initially seemed promising. However, the produced
musl binary build segfaulted on my Debian machine. I don't know about
the Mac and Windows binaries. I then tried switching to building with
a vendored OpenSSL (cac93e2793), but then the build started failing
(https://github.com/martinvonz/jj/actions/runs/1978730621). I couldn't
figure out why it failed, so I decided to do the build in a more
manual way (without rust-build/rust-build.action), based on
https://github.com/gitext-rs/git-stack/blob/main/.github/workflows/post-release.yml
(thanks to @epage for the example and to @arxanas for the link). I
could simplify it a bit because I'm currently doing the releases via
the GitHub UI (epage's original triggers the release when a tag has
been pushed, IIUC). Let's hope that it works this time.
I was able to build a working musl binary with this change, by running
this command:
```
cargo build --release --target x86_64-unknown-linux-musl
```
Thanks to @arxanas for the tip.
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.
There's been *a lot* of changes since 0.2.0 almost a year ago. With
the attention the project has gotten recently, I feel like I should
cut a new release and start keeping a changelog. So let's start by
bumping the version to 0.3.0.
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.
I'm not sure it'll be useful, but it seems nice to be able to set the
same values via config or environment variables. Perhap we should
simply use `config::Environment` to make everything configurable via
environment variables, but I'll leave that for later.
