mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-12-01 03:45:55 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2
jj/CHANGELOG.md

397 lines
16 KiB
Markdown
Raw Normal View History

release: add a changelog
2022-03-12 18:48:51 +00:00
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
revset: remove redundant candidates argument from filter predicates
2022-10-25 13:08:11 +00:00
### Breaking changes
* Dropped candidates set argument from `description(needle)`, `author(needle)`,
revset: remove redundant candidates argument from merges() Since 'merges()' just filters the candidates set per item, it doesn't need a candidates argument. Perhaps, 'merges(x)' could be a predicate to select merge commits within a subgraph 'x', but I don't know if that would be useful.
2022-10-25 13:20:59 +00:00
`committer(needle)`, `merges()` revsets. Use `x & description(needle)`
instead.
revset: remove redundant candidates argument from filter predicates
2022-10-25 13:08:11 +00:00
revset: give higher precedence to intersection/difference operators Just like hg revsets and major programming languages.
2022-11-16 14:35:12 +00:00
* Adjusted precedence of revset union/intersection/difference operators.
`x | y & z` is now equivalent to `x | (y & z)`.
cli: drop support for `ui.enable-open-commits` config
2022-11-05 01:24:20 +00:00
* Support for open commits has been dropped. The `ui.enable-open-commits` config
cli: remove `open`/`close` commands
2022-11-05 00:15:35 +00:00
that was added in 0.5.0 is no longer respected. The `jj open/close` commands
have been deleted.
* `jj commit` is now a separate command from `jj close` (which no longer
exists). The behavior has changed slightly. It now always asks for a
description, even if there already was a description set. It now also only
works on the working-copy commit (there's no `-r` argument).
cli: add `commit` as its own command (not an alias for `close`) It seems very likely that we're going to remove support for open commits, but it's still useful to have a `commit` command that lets the user enter a description and starts a new change. Calling it `commit` seems good to make the transition from other VCSs simpler.
2022-10-29 21:48:13 +00:00
cli: add git remote rename subcommand
2022-10-19 18:44:39 +00:00
### New features
ui: add pager Teach Ui's writing functions to write to a pager without touching the process's file descriptors. This is done by introducing UiOutput::Paged, which spawns a pager that Ui's functions can write to. The pager program can be chosen via `ui.pager`. (defaults to Defaults to $PAGER, and 'less' if that is unset (falling back to 'less' also makes the tests pass). Currently, commands are paginated if: - they have "long" output (as defined by jj developers) - jj is invoked in a terminal The next commit will allow pagination to be turned off via a CLI option. More complex pagination toggling (e.g. showing a pager even if the output doesn't look like a terminal, using a pager for shorter ouput) is left for a future PR.
2022-10-18 18:07:35 +00:00
* Commands with long output are paginated.
cli: add git remote rename subcommand
2022-10-19 18:44:39 +00:00
* The new `jj git remote rename` command allows git remotes to be renamed
in-place.
Documentation for `jj resolve` and merge tool config
2022-10-30 08:23:45 +00:00
* The new `jj resolve` command allows resolving simple conflicts with
an external 3-way-merge tool.
cli: search @- for branches to push when @ has none
2022-10-20 21:18:34 +00:00
* `jj git push` will search `@-` for branches to push if `@` has none.
revset: extend file() predicate to accept more than one paths 'file(a, b)' could be expressed as 'file(a) | file(b)', but the former is easier to type and can be evaluated efficiently without optimization step.
2022-11-01 08:11:22 +00:00
* The new revset function `file(pattern..)` finds commits modifying the
paths specified by the `pattern..`.
revset: implement file(pattern[, candidates]) predicate The name "file()" is just copied from hg. I'm not sure if it's good in jj's context, but I couldn't find a better name.
2022-10-23 04:14:00 +00:00
revset: add empty() predicate to find commits with no file change The expression 'x ~ empty()' is identical to 'x & file(".")', but more intuitive. Note that 'x ~ empty()' is slower than 'x & file(".")' since the negative intersection isn't optimized right now. I think that can be handled as follows: 'x ~ filter(f)' -> 'x & filter(!f)' -> 'filter(!f, x)'
2022-11-15 08:12:37 +00:00
* The new revset function `empty()` finds commits modifying no files.
revset: implement function alias expansion Function parameters are processed as local symbols while substituting alias expression. This isn't as efficient as Mercurial which caches a tree of fully-expanded function template, but that wouldn't matter in practice.
2022-11-26 11:41:55 +00:00
* Added support for revset aliases. New symbols and functions can be configured
by `revset-aliases.<name> = <expression>`.
cli: load revset aliases from config file Aliases are loaded at WorkspaceCommandHelper::new() as it's easier to warn invalid declarations there. Not all commands use revsets, but many do, so I think it's okay to always pay the loading cost. Parsing the declaration part (i.e. a symbol) should be fast anyway. The nested error message isn't super readable, but seems good enough. Config syntax to bikeshed: - naming: [revset-alias] vs [revset-aliases] ? - function alias will need quotes: 'f(x)' = 'x'
2022-11-25 10:27:13 +00:00
changelog: fix typo ("specity")
2022-11-07 21:35:34 +00:00
* It is now possible to specify configuration options on the command line
changelog: fix typo ("he" instead of "the")
2022-11-14 17:26:04 +00:00
with the new `--config-toml` global option.
Add --config-toml command-line argument for additional TOML config Unfortunately, TOML requires quotes around the argument. So, the usage is `jj --config-toml ui.color=\"always\"` in bash. The plan is to eventually have a `--config` option with simpler syntax for simple cases. As discussed in https://github.com/martinvonz/jj/discussions/688.
2022-10-31 01:29:26 +00:00
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* `jj git` subcommands will prompt for credentials when required for HTTPS
remotes rather than failing.
[#469](https://github.com/martinvonz/jj/issues/469)
git: prompt for credentials when needed
2022-11-06 18:15:44 +00:00
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* Branches that have a different target on some remote than they do locally are
now indicated by an asterisk suffix (e.g. `main*`) in `jj log`.
[#254](https://github.com/martinvonz/jj/issues/254)
templater: indicate if branch needs to be pushed to a remote It's useful to know when you've modified a branch that exists on a remote. A typical case is when you have pushed a branch to a remote and then rewritten it. This commit adds an indication in the `branches` template keyword. A branch that needs to be pushed to a remote now has a `*` at the end (similar to how conflicted branches have a `?` at the end). Note that the indication only considers remotes where the branch currently exists, so there won't be an indication that the branch has not been pushed to a remote. Closes #254
2022-11-04 16:39:46 +00:00
log: move commit ID off to the right We have talked about showing the commit ID only for divergent changes because it's generally easier to work with the change ID, and it's less likely to result in a divergent change. However, it's useful to have the commit ID available for pasting into e.g. a commit message or the GitHub UI. To try to steer users towards using the change ID, this commit moves the commit ID off to the right in the log output. I put it just after the "divergent" field, because that makes it close to how I imagine it would look if we decided to hide the commit ID except for divergent changes. I was thinking that could be rendered as "divergent (abc123)". So if we add config to hide the commit ID, then it would be rendered almost the same for divergent commits (just with the added parentheses). It would also make sense to replace the "divergent" field by a question mark on the change ID, since change IDs basically behave like branches. If we do that, then the placement of the commit ID I picked in this commit does not make sense.
2022-11-13 18:01:11 +00:00
* The commit ID was moved from first on the line in `jj log` output to close to
the end. The goal is to encourage users to use the change ID instead, since
that is generally more convenient, and it reduces the risk of creating
divergent commits.
operations: make hostname and username configurable We currently get the hostname and username from the `whoami` crate. We do that in lib crate, without giving the caller a way to override them. That seems wrong since it might be used in a server and performing operations on behalf of some other user. This commit makes the hostname and username configurable, so the calling crate can pass them in. If they have not been passed in, we still default to the values from the `whoami` crate.
2022-11-13 06:29:06 +00:00
* The username and hostname that appear in the operation log are now
configurable via config options `operation.username` and `operation.hostname`.
feature: support git credential helpers
2022-11-20 00:13:39 +00:00
* `jj git` subcommands now support credential helpers.
log: warn if the provided path looks like a revset
2022-11-18 23:41:35 +00:00
* `jj log` will warn if it appears that the provided path was meant to be a
revset.
feature: add verbose flag and tracing library
2022-11-20 03:38:25 +00:00
* The new global flag `-v/--verbose` will turn on debug logging to give
some additional insight into what is happening behind the scenes.
Note: This is not comprehensively supported by all operations yet.
feature: support relative timestamps as a config option
2022-11-26 01:33:24 +00:00
* `jj log`, `jj show`, and `jj obslog` now all support showing relative
timestamps by setting `ui.relative-timestamps = true` in the config file.
repo: forbid checking out the root commit Prevents `jj edit root` from succeeding, which would otherwise place the repo in a state where every operation panics.
2022-10-20 23:33:14 +00:00
### Fixed bugs
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* A bug in the export of branches to Git caused spurious conflicted branches.
This typically occurred when running in a working copy colocated with Git
(created by running `jj init --git-dir=.`).
[#463](https://github.com/martinvonz/jj/issues/463)
git: when exporting, don't overwrite changes made by git This fixes the bugs shown by the tests added in the previous patch by checking that the git branches we're about to update have not been updated by git since our last export. If they have, we fail those branches. The user can then re-import from the git repo and resolve any conflicts before exporting again. I had to update the `test_export_import_sequence` to make it pass. That shows a new bug, which I'll fix next. The problem is that the exported view doesn't get updated on import, so we would try to export changes compared to an earlier export, even though we actually knew (because of the `jj git import`) that the state in git had changed.
2022-12-02 23:09:07 +00:00
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* When exporting branches to Git, we used to fail if some branches could not be
exported (e.g. because Git doesn't allow a branch called `main` and another
branch called `main/sub`). We now print a warning about these branches
changelog: list fix for #493 was a bugfix, not a feature
2022-12-03 08:02:15 +00:00
instead.
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
[#493](https://github.com/martinvonz/jj/issues/493)
changelog: list fix for #493 was a bugfix, not a feature
2022-12-03 08:02:15 +00:00
git: when exporting, don't overwrite changes made by git This fixes the bugs shown by the tests added in the previous patch by checking that the git branches we're about to update have not been updated by git since our last export. If they have, we fail those branches. The user can then re-import from the git repo and resolve any conflicts before exporting again. I had to update the `test_export_import_sequence` to make it pass. That shows a new bug, which I'll fix next. The problem is that the exported view doesn't get updated on import, so we would try to export changes compared to an earlier export, even though we actually knew (because of the `jj git import`) that the state in git had changed.
2022-12-02 23:09:07 +00:00
* If you had modified branches in jj and also modified branches in conflicting
ways in Git, `jj git export` used to overwrite the changes you made in Git.
We now print a warning about these branches instead.
repo: forbid checking out the root commit Prevents `jj edit root` from succeeding, which would otherwise place the repo in a state where every operation panics.
2022-10-20 23:33:14 +00:00
* `jj edit root` now fails gracefully.
git: don't abandon HEAD commit when it loses a branch I was trying to create a reproduction script for #412, but the script ran into another bug first. The script removed all the local and remote branches from the backing Git repo. I noticed that we would then try to abandon all commits. We should still count Git HEAD's target as visible and not try to abandon it. This patch fixes that.
2022-10-28 19:39:28 +00:00
* `jj git import` used to abandon a commit if Git branches and tags referring
to it were removed. We now keep it if a detached HEAD refers to it.
git: don't abandon root commit when all refs are gone If you remove all refs from the backing Git repo and then run `jj git import`, we would see that all commits disappeared from the Git repo, so we would remove them from the jj repo too. However, we do that by doing a history walk from old heads to the new heads, which includes the root commit when the new heads is an empty set. That means that we mark the root commit as abandoned, which led to a crash in `rewrite.rs` (when we try pick the root commit's first parent to use as parent for rebased commits).
2022-10-28 23:18:56 +00:00
* `jj git import` no longer crashes when all Git refs are removed.
git: do not delete or track git submodules. A new FileType, GitSubmodule is added which is ignored. Files or directories having this type are not added to the work queue and are ignored in snapshot. Submodules are not created by jujutsu when resetting or checking out a tree, they should be currently managed using git.
2022-11-23 19:34:38 +00:00
* Git submodules are now ignored completely. Earlier, files present in the
submodule directory in the working copy would become added (tracked), and
later removed if you checked out another commit. You can now use `git` to
populate the submodule directory and `jj` will leave it alone.
git: on import, add GC-preventing refs to all seen refs To prevent git's GC from breaking a repo, we already add a git ref to commits we create in the git backend. However, we don't add refs to commits we import from git. This fixes that. Closes #815.
2022-12-03 17:49:09 +00:00
* Git's GC could remove commits that were referenced from jj in some cases. We
are now better at adding Git refs to prevent that.
[#815](https://github.com/martinvonz/jj/issues/815)
changelog: thank people who contributed to a release Thanks, everyone! :) I'm happy to rephrase the text. I included people in order of their first contribution in the release. I included their full name and the GitHub username.
2022-11-28 07:38:17 +00:00
### Contributors
Thanks to the people who made this release happen!
* Martin von Zweigbergk (@martinvonz)
* Benjamin Saunders (@Ralith)
* Yuya Nishihara (@yuja)
* Glen Choo (@chooglen)
* Ilya Grigoriev (@ilyagr)
* Ruben Slabbert (@rslabbert)
* Waleed Khan (@arxanas)
readme: add some badges Originally written by @xxxserxxx.
2022-11-30 16:43:13 +00:00
* Sean E. Russell (@xxxserxxx)
git: do not delete or track git submodules. A new FileType, GitSubmodule is added which is ignored. Files or directories having this type are not added to the work queue and are ignored in snapshot. Submodules are not created by jujutsu when resetting or checking out a tree, they should be currently managed using git.
2022-11-23 19:34:38 +00:00
* Pranay Sashank (@pranaysashank)
changelog: thank people who contributed to a release Thanks, everyone! :) I'm happy to rephrase the text. I included people in order of their first contribution in the release. I included their full name and the GitHub username.
2022-11-28 07:38:17 +00:00
release: release version 0.5.1 This point of this release is just to trigger the release automation on GitHub.
2022-10-18 04:45:04 +00:00
## [0.5.1] - 2022-10-17
No changes (just trying to get automated GitHub release to work).
release: release version 0.5.0 It's been several months since the last release and a lot has changed. Probably the biggest change is that open commits are now disabled by default.
2022-10-17 20:41:46 +00:00
## [0.5.0] - 2022-10-17
cli: make operation to undo or restore to a positional argument 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.
2022-04-24 19:31:54 +00:00
### Breaking changes
cli: disable open commits by default
2022-08-25 22:18:14 +00:00
* Open commits are now disabled by default. That means that `jj checkout` will
always create a new change on top of the specified commit and will let you
edit that in the working copy. Set `ui.enable-open-commits = true` to restore
the old behavior and let us know that you did so we know how many people
prefer the workflow with open commits.
cli: make operation to undo or restore to a positional argument 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.
2022-04-24 19:31:54 +00:00
* `jj [op] undo` and `jj op restore` used to take the operation to undo or
restore to as an argument to `-o/--operation`. It is now a positional
argument instead (i.e. `jj undo -o abc123` is now written `jj undo abc123`).
cli: make invalid alias definition an error
2022-05-07 13:57:13 +00:00
* An alias that is not configured as a string list (e.g. `my-status = "status"`
instead of `my-status = ["status"]`) is now an error instead of a warning.
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* `jj log` now defaults to showing only commits that are not on any remote
branches (plus their closest commit on the remote branch for context). This
set of commits can be overridden by setting `ui.default-revset`. Use
`jj log -r 'all()'` for the old behavior. Read more about revsets
cli: make `log` show only local commits by default The default log output of showing all commits is not very useful when contributing to an existing repo. Let's have it default to showing commits not on any remote branch instead. I think that's the best we can do since we don't have a configurable main branch yet, and we don't even have per-repo configuration.. Closes #250.
2022-05-14 15:55:46 +00:00
[here](https://github.com/martinvonz/jj/blob/main/docs/revsets.md).
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
[#250](https://github.com/martinvonz/jj/issues/250)
cli: make `log` show only local commits by default The default log output of showing all commits is not very useful when contributing to an existing repo. Let's have it default to showing commits not on any remote branch instead. I think that's the best we can do since we don't have a configurable main branch yet, and we don't even have per-repo configuration.. Closes #250.
2022-05-14 15:55:46 +00:00
cli: make `jj new` always check out the new commit Before this change, `jj new` would check out the new commit only if it was created on top of the current commit. I never liked that special-casing, and after thinking more about how the open/closed should work (see discussion #321), I think we want `jj new` to behave similar to how `git/hg checkout` works, so it can effectively replace the current `jj checkout` command for the use case of starting new work on top of an existing commit.
2022-05-21 13:38:56 +00:00
* `jj new` now always checks out the new commit (used to be only if the parent
was `@`).
cli: make `jj merge` delegate to `jj new`
2022-08-31 05:31:18 +00:00
* `jj merge` now checks out the new commit. The command now behaves exactly
like `jj new`, except that it requires at least two arguments.
rewrite: create new checkout on top iff commit abandoned When rebasing commits after rewrites, we also update all workspaces' checkouts. If the new commit is closed, we create a new commit on top. Since we're hoping to remove the open/closed concept, we need a new condition. I considered creating a new commit on top if the change ID was different from before the rewrite. However, that would make at least `jj split` more complicated because it makes the first commit keep the change ID but it wants the second commit to be checked out. This patch instead creates the new commit on top only when the original commit was abandoned.
2022-06-23 09:14:11 +00:00
* When the working-copy commit is abandoned by `jj abandon` and the parent
commit is open, a new working-copy commit will be created on top (the open
parent commit used to get checked out).
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* `jj branch` now uses subcommands like `jj branch create` and
cli: make `jj branch` take subcommands, not flags As per https://github.com/martinvonz/jj/issues/330.
2022-06-06 03:23:01 +00:00
`jj branch forget` instead of options like `jj branch --forget`.
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
[#330](https://github.com/martinvonz/jj/issues/330)
cli: make `jj branch` take subcommands, not flags As per https://github.com/martinvonz/jj/issues/330.
2022-06-06 03:23:01 +00:00
config: move NO_COLOR handling from ui, don't override user setting According to the NO_COLOR FAQ, "user-level configuration files [...] should override $NO_COLOR." https://no-color.org/ Unfortunately this makes it harder to test the $NO_COLOR behavior since the test environment isn't attached to a tty. We could allocate a pty or LD_PRELOAD shim to intercept isatty(), but I feel it would be too much to do. https://github.com/assert-rs/assert_cmd/issues/138
2022-06-10 02:42:15 +00:00
* The [`$NO_COLOR` environment variable](https://no-color.org/) no longer
overrides the `ui.color` configuration if explicitly set.
cli: add `jj edit` for editing a commit in the wokring copy
2022-06-28 00:36:13 +00:00
* `jj edit` has been renamed to `jj touchup`, and `jj edit` is now a new command
with different behavior. The new `jj edit` lets you edit a commit in the
working copy, even if the specified commit is closed.
cli: rename `jj edit` to `jj touchup`
2022-06-19 03:22:54 +00:00
cli: allow pushing open commits Since we're thinking of removing the concept of open and closed commits, we can't use that open/closed distinction to decide to not push some commits.
2022-06-19 03:05:08 +00:00
* `jj git push` no longer aborts if you attempt to push an open commit (but it
now aborts if a commit does not have a description).
cli: push only branches pointing to `@` by default Since we now allow pushing open commits, we can implement support for pushing the "current" branch by defining a "current" branch as any branch pointing to `@`. That definition of a current/active seems to have been the consensus in discussion #411. Closes #246.
2022-07-13 04:14:02 +00:00
* `jj git push` now pushes only branches pointing to the `@` by default. Use
`--all` to push all branches.
cli: rename `checkout` to `working_copy` in template
2022-09-18 21:46:12 +00:00
* The `checkouts` template keyword is now called `working_copies`, and
`current_checkout` is called `current_working_copy`.
cli: add a command for printing the contents of a file in a revision 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.
2022-04-06 18:00:27 +00:00
### New features
cli: add interdiff command Add the `jj interdiff` command for comparing only the diffs of commits. Its args are identical to that of `jj diff`, minus `--revision` (because interdiff always requires two commits). Like `jj obslog -p`, Changes introduced by intervening commits are ignored by rebasing `--from` onto `--to` 's parents.
2022-08-30 18:47:38 +00:00
* The new `jj interdiff` command compares the changes in commits, ignoring
changes from intervening commits.
cli: add mode for rebasing branch onto destination (#168)
2022-04-13 17:53:50 +00:00
* `jj rebase` now accepts a `--branch/-b <revision>` argument, which can be used
instead of `-r` or `-s` to specify which commits to rebase. It will rebase the
cli: make `jj rebase` default to `-b @` (#168) Closes #168.
2022-04-14 06:53:35 +00:00
whole branch, relative to the destination. The default mode has changed from
`-r @` to `-b @`.
cli: add mode for rebasing branch onto destination (#168)
2022-04-13 17:53:50 +00:00
cli: add a command for printing the contents of a file in a revision 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.
2022-04-06 18:00:27 +00:00
* The new `jj print` command prints the contents of a file in a revision.
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* The new `jj git remotes list` command lists the configured remotes and their
URLs.
[#243](https://github.com/martinvonz/jj/issues/243)
cli: add a command for listing git remotes and their URLs 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
2022-04-25 20:34:13 +00:00
cli: teach `jj squash` to move only changes to specified paths
2022-04-09 17:27:17 +00:00
* `jj move` and `jj squash` now lets you limit the set of changes to move by
specifying paths on the command line (in addition to the `--interactive`
mode). For example, use `jj move --to @-- foo` to move the changes to file
(or directory) `foo` in the working copy to the grandparent commit.
cli: teach `jj move` to move only changes to specified paths 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>`.
2022-04-09 16:58:33 +00:00
changelog: asking for a combined description is a feature, not a bug fix I suppose it could be seen as a bug fix that we no longer discard a description without asking, but it was intentionally done the way it was before. While at it, I also clarified that the source commit gets abandoned if it becomes empty.
2022-08-31 05:24:35 +00:00
* When `jj move/squash/unsquash` abandons the source commit because it became
empty and both the source and the destination commits have non-empty
descriptions, it now asks for a combined description. If either description
was empty, it uses the other without asking.
cli: teach `jj split` to include all specified paths in first commit
2022-04-09 18:35:28 +00:00
* `jj split` now lets you specify on the CLI which paths to include in the first
commit. The interactive diff-editing is not started when you do that.
cli: add commands for working with sparse patterns (#52) 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.
2022-02-06 23:10:50 +00:00
* Sparse checkouts are now supported. In fact, all working copies are now
"sparse", only to different degrees. Use the `jj sparse` command to manage
cli: `jj branch` can accept any number of branches
2022-05-02 19:58:32 +00:00
the paths included in the sparse checkout.
cli: add commands for working with sparse patterns (#52) 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.
2022-02-06 23:10:50 +00:00
cli: allow config in `~/.jjconfig.toml` As I said in 095fb9fef4b1, 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`.
2022-05-08 06:54:51 +00:00
* Configuration is now also read from `~/.jjconfig.toml`.
cli: if `$JJ_CONFIG` points to a directory, read all files in it 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.
2022-04-09 23:14:42 +00:00
* The `$JJ_CONFIG` environment variable can now point to a directory. If it
does, all files in the directory will be read, in alphabetical order.
cli: respect `$VISUAL`, overriding `$EDITOR` With this patch, the order is this: `$JJ_EDITOR` environement variable `ui.editor` config `$VISUAL` environement variable `$EDITOR` environement variable `pico` That matches git, except that git falls back to an editor determined at compile time (usually `vi`) instead of using `pico`.
2022-05-10 17:04:10 +00:00
* The `$VISUAL` environment is now respected and overrides `$EDITOR`. The new
`ui.editor` config has higher priority than both of them. There is also a new
`$JJ_EDITOR` environment variable, which has even higher priority than the
config.
cli: allow overriding `$EDITOR` variable by `ui.editor` config
2022-04-10 05:42:27 +00:00
revsets: allow single internal `-` and `+` characters in symbols (#46)
2022-04-27 16:42:18 +00:00
* You can now use `-` and `+` in revset symbols. You used to have to quote
branch names like `my-feature` in nested quotes (outer layer for your shell)
like `jj co '"my-feature"'`. The quoting is no longer needed.
revset: add a `connected()` function This introduces a `connected(x)` function, which is simply the same as `x:x`. It's occasionally useful if `x` is a long expression. It's also useful as a building block for `root(x)` (coming soon).
2022-04-14 04:26:21 +00:00
* The new revset function `connected(x)` is the same as `x:x`.
revset: add a `roots()` function
2022-04-13 20:55:47 +00:00
* The new revset function `roots(x)` finds commits in the set that are not
descendants of other commits in the set.
Remove out-of-date parenthetical in tutorial.md
2022-04-23 04:30:33 +00:00
* ssh-agent is now detected even if `$SSH_AGENT_PID` is not set (as long as
`$SSH_AUTH_SOCK` is set). This should help at least macOS users where
ssh-agent is launched by default and only `$SSH_AUTH_SOCK` is set.
git: when importing refs, abandon commits that were abandoned in git Now that I'm using GitHub PRs instead of pushing directly to the main branch, it's quite annoying to have to abandon the old commits after GitHub rebases them. This patch makes it so we compare the remote's previous heads to the new heads and abandons any commits that were removed on the remote. As usual, that means that descendants get rebased onto the closest remaining commit. This is half of #241. The other half is to detect rewritten branches and rebase on top.
2022-03-27 05:33:08 +00:00
* When importing from a git, any commits that are no longer referenced on the
git side will now be abandoned on the jj side as well. That means that
`jj git fetch` will now abandon unreferenced commits and rebase any local
changes you had on top.
cli: add a mode of pushing with branch taken from change ID 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.
2022-04-29 03:58:41 +00:00
* `jj git push` gained a `--change <revision>` argument. When that's used, it
will create a branch named after the revision's change ID, so you don't have
Add configuration option to override branch name prefix.
2022-05-24 09:52:45 +00:00
to create a branch yourself. By default, the branch name will start with
`push-`, but this can be overridden by the `push.branch-prefix` config
setting.
cli: add a mode of pushing with branch taken from change ID 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.
2022-04-29 03:58:41 +00:00
cli: prevent pushing commits without description, author, or committer This patch prevents perhaps pushing commits with an empty description or the placeholder "(no user/email configured)" values for author/committer. Closes #322.
2022-05-27 15:54:47 +00:00
* `jj git push` now aborts if you attempt to push a commit without a
description or with the placeholder "(no name/email configured)" values for
author/committer.
diff_edit: load command arguments from merge-tools.<name> config Apparently, I need to pass `--merge` option to use kdiff3 as a diff editor. We could add `diff-editor-args` or extend `diff-editor` to a list of command arguments, but we'll eventually add stock merge tools and the configuration would look like: [merge-tools.<name>] program = ... diff-args = [...] edit-args = [...] merge-args = [...]
2022-05-01 01:45:22 +00:00
* Diff editor command arguments can now be specified by config file.
Example:
[merge-tools.kdiff3]
program = "kdiff3"
edit-args = ["--merge", "--cs", "CreateBakFiles=0"]
cli: `jj branch` can accept any number of branches
2022-05-02 19:58:32 +00:00
* `jj branch` can accept any number of branches to update, rather than just one.
cli: allow alias after global args, and recursive aliases Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That makes `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
2022-05-01 15:54:35 +00:00
* Aliases can now call other aliases.
cli: teach `log` flag to show commits in reverse order This adds a `--reversed` flag to `jj log` to show commits with later commits further down. It works both with and without the graph. Since the graph-drawing code is already independent of the relationship between commits, it doesn't need any updating.
2022-05-09 17:38:23 +00:00
* `jj log` now accepts a `--reversed` option, which will show older commits
first.
cli: add basic support for 'jj log PATH' In the current implementation, tree is diffed twice if both PATH and -p are specified. If this adds significant cost, we'll need to reimplement it without using a revset abstraction (or maybe adjust revset/graph API.)
2022-09-13 07:26:23 +00:00
* `jj log` now accepts file paths.
cli: teach `obslog` an option to show diff This patch adds `jj obslog -p` for including the diff compared to the predecessor (the first predecessor if there are several). If the predecessor's parents are different, then we create a temporary tree by rebasing the predecessor to have the same parents and we use the result as base for the diff. That way, we avoid polluting the diff with the changes caused by the rebase. (I don't think we currently have any commands that can change both parents and content, so the diff should always be empty for rewrites caused by a rebase.) Working on this also reminded me that it'll be really nice when we replace `jj obslog` by something based on the operation log - I really miss seeing information about the operation in the output (like `hg obslog` gets from its obsmarkers).
2022-06-03 22:25:56 +00:00
* `jj obslog` now accepts `-p`/`--patch` option, which will show the diff
compared to the previous version of the change.
CommitBuilder: when rewriting commit, replace placeholder user/email If a commit's author field has the placeholder user/email values (i.e. "(no name configured)" and "(no email configured)"), and they have now configured their email and username, they probably want us to update the author field with the new information, so that's what this patch does. Thanks to durin42@ for the suggestion on #322.
2022-06-04 23:18:03 +00:00
* The "(no name/email configured)" placeholder value for name/email will now be
replaced if once you modify a commit after having configured your name/email.
cli: parse --color option and reconfigure ui I often redirect the jj output to pager, so I set ui.color = "always" in config file. This patch allows me to remove such config, and instead specify --color=always only when needed.
2022-06-09 04:16:34 +00:00
* Color setting can now be overridden by `--color=always|never|auto` option.
cli: teach `jj checkout` a `-m` flag, to match `jj new` The two commands are very similar and we should probably make one an alias of the other (or just delete one), but for now let's at least make them more similar by supporting `-m` for both. I currently think `jj new` is more natural when starting a new change on top of the current one and `jj checkout` is more natural when starting a new change on top of another one, as well as when you just want to look around or run tests. `jj checkout` doesn't currently default to the working copy like `jj new` does. Perhaps we should make it do that. Will people eventually feel that it's natural to run `jj checkout` to create a new change on top of the working copy, or will they feel that it's natural to run `jj new` on an unrelated commit even to just look around, or will we want them as synonyms forever?
2022-08-27 05:03:51 +00:00
* `jj checkout` now lets you specify a description with `--message/-m`.
cli: make `jj new` create a merge commit if more than one arg given `jj merge` just creates an empty change, which is practically the same as `jj new`. The main difference is that the former requires more than one argument and the latter requires at most one argument. It seems cleaner to generalize them and make them aliases. This patch starts doing that by making `jj new` accept more than one argument. Instead of having `jj merge` be exactly an alias for `jj new`, we may want to make it a thin wrapper that just checks that more than one argument was given. That would probably be less confusing to users who run `jj merge` without arguments to see what it does. We should probably make `jj checkout` also be an alias for `jj new`, but that will have to wait until we have removed support for open commits (since `jj checkout` still has logic for dealing with open commits).
2022-08-31 04:35:56 +00:00
* `jj new` can now be used for creating merge commits. If you pass more than
one argument to it, the new commit will have all of them as parents.
cli: print errors to stderr
2022-04-07 06:25:01 +00:00
### Fixed bugs
merge: fix modify/delete conflict to not resolve
2022-04-06 19:18:24 +00:00
* When rebasing a conflict where one side modified a file and the other side
deleted it, we no longer automatically resolve it in favor of the modified
content (this was a regression from commit c0ae4b16e8c4).
cli: print errors to stderr
2022-04-07 06:25:01 +00:00
* Errors are now printed to stderr (they used to be printed to stdout).
working_copy: fix crash when updating and only executable bit changed
2022-04-15 06:03:08 +00:00
* Updating the working copy to a commit where a file's executable bit changed
but the contents was the same used to lead to a crash. That has now been
cli: `jj branch` can accept any number of branches
2022-05-02 19:58:32 +00:00
fixed.
working_copy: fix crash when updating and only executable bit changed
2022-04-15 06:03:08 +00:00
trees: when merging trees and one is missing, treat it as empty When a directory is missing in one merge input (base or one side), we would consider that a merge conflict. This patch changes that so we instead merge trees by treating the missing tree as empty.
2022-04-18 03:51:24 +00:00
* If one side of a merge modified a directory and the other side deleted it, it
used to be considered a conflict. The same was true if both sides added a
directory with different files in. They are now merged as if the missing
directory had been empty.
rebase: update bookkeeping for branches as we rebase descendants 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.
2022-04-23 05:58:16 +00:00
* When using `jj move` to move part of a commit into an ancestor, any branches
pointing to the source commit used to be left on a hidden intermediate commit.
They are now correctly updated.
cli: require at least one path for `jj untrack` 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`).
2022-04-09 16:20:00 +00:00
* `jj untrack` now requires at least one path (allowing no arguments was a UX
bug).
cli: require at least one destination for rebase Rebasing onto no commits (i.e. onto the root commit) is almost definitely not what you meant to do if you run `jj rebase` (without any arguments).
2022-04-11 17:40:56 +00:00
* `jj rebase` now requires at least one destination (allowing no arguments was a
UX bug).
cli: make `jj restore --to <rev>` restore from the working copy
2022-04-24 19:13:43 +00:00
* `jj restore --to <rev>` now restores from the working copy (it used to restore
from the working copy's parent).
cli: don't crash if $EDITOR fails
2022-04-09 22:53:32 +00:00
* You now get a proper error message instead of a crash when `$EDITOR` doesn't
exist or exits with an error.
cli: allow alias after global args, and recursive aliases Our support for aliases is very naively implemented; it assumes the alias is the first argument in argv. It therefore fails to resolve aliases after global arguments such as `--at-op`. This patch fixes that by modifying the command defintion to have an "external subcommand" in the list of available commands. That makes `clap` give us the remainder of the arguments when it runs into an unknown command. The first in the list will then be an alias or simply an unknown command. Thanks to @epage for the suggestion on in clap-rs/clap#3672. With the new structure, it was easy to handle recursive alias definitions, so I added support for that too. Closes #292.
2022-05-01 15:54:35 +00:00
* Global arguments, such as `--at-op=<operation>`, can now be passed before
an alias.
cli: use `.` in output for current directory instead of empty string
2022-04-20 05:15:38 +00:00
* Fixed relative path to the current directory in output to be `.` instead of
empty string.
cli: some fixes and touch-ups for `jj workspace`, plus tests
2022-04-22 04:49:57 +00:00
* When adding a new workspace, the parent of the current workspace's current
checkout will be checked out. That was always the intent, but the root commit
was accidentally checked out instead.
checkout: don't abandon old commit if it has non-empty description If the user entered a description, we shouldn't abandon it even if it has no changes to the content.
2022-05-21 17:23:46 +00:00
* When checking out a commit, the previous commit is no longer abandoned if it
has a non-empty description.
cli: snapshot working copy even on e.g. `jj diff -r <some hash>` I was initially worried about the cost of always snapshotting the working copy, so that's why e.g. `jj diff -r <some hash>` doesn't do it. However, there's been a few caused by missing snapshotting, and there are still a few (I just noticed it in `jj undo` while writing this patch). Let's always do the snapshotting and if the user really doesn't want it, they can pass `--no-commit-working-copy` (which we should probably rename to `--no-snapshot-working-copy` or maybe just `--no-snapshot`). That should reduce bugs and make the CLI more predictable. Two test cases were affected becasue `jj merge` also didn't snapshot the working copy. Before this patch, e.g. `jj co --no-commit-working-copy` would error out, but now it will succeed (without touching the working copy, leaving the working copy stale). That may be confusing, but it should be easy to recover from (e.g. by `jj undo`). We can consider adding a check for it later if it seems too confusing (it's probably rarely something the user wanted).
2022-07-15 18:09:11 +00:00
* All commands now consistently snapshot the working copy (it was missing from
e.g. `jj undo` and `jj merge` before).
release: release version 0.4.0 This release is mostly about the fix for #177, which looks pretty bad even though I think it is actually harmless. It also has `jj log -p` contributed by @yuja!
2022-04-03 05:56:59 +00:00
## [0.4.0] - 2022-04-02
config: drop support for `~/.jjconfig` I'm a little hesitant to do this because most tools I'm familiar with have the config file directly in `~/`. It's also easier to describe where to put the file if it doesn't vary across platforms. But we're still early in the project, so let's try it and see if we get any complaints.
2022-03-19 17:17:30 +00:00
### Breaking changes
* Dropped support for config in `~/.jjconfig`. Your configuration is now read
from `<config dir>/jj/config.toml`, where `<config dir>` is
`${XDG_CONFIG_HOME}` or `~/.config/` on Linux,
`~/Library/Application Support/` on macOS, and `~\AppData\Roaming\` on
Windows.
config: add support for a `$JJ_CONFIG` environment variable 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).
2022-03-19 17:37:13 +00:00
### New features
* You can now set an environment variable called `$JJ_CONFIG` to a path to a
config file. That will then be read instead of your regular config file. This
is mostly intended for testing and scripts.
cli: respect `$NO_COLOR` environment variable
2022-03-19 17:00:13 +00:00
* The [standard `$NO_COLOR` environment variable](https://no-color.org/) is now
respected.
cli: teach `jj new` to set initial description with `-m` I rarely use `jj new`, so this feature is mostly for use in tests.
2022-03-26 21:02:04 +00:00
* `jj new` now lets you specify a description with `--message/-m`.
repo: don't abandon empty commit if it has descendants 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.
2022-03-26 21:53:51 +00:00
* When you check out a commit, the old commit no longer automatically gets
abandoned if it's empty and has descendants, it only gets abandoned if it's
empty and does not have descendants.
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
* When undoing an earlier operation, any new commits on top of commits from the
undone operation will be rebased away. For example, let's say you rebase
commit A so it becomes a new commit A', and then you create commit B on top of
A'. If you now undo the rebase operation, commit B will be rebased to be on
top of A instead. The same logic is used if the repo was modified by
concurrent operations (so if one operation added B on top of A, and one
repo: when merging in removed head, rebase descendants (#111)
2022-03-17 03:58:04 +00:00
operation rebased A as A', then B would be automatically rebased on top of
A'). See #111 for more examples.
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
[#111](https://github.com/martinvonz/jj/issues/111)
repo: when merging in removed head, rebase descendants (#111)
2022-03-17 03:58:04 +00:00
log: add -p/--patch option to show diff along with commit meta data "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().
2022-03-28 09:12:08 +00:00
* `jj log` now accepts `-p`/`--patch` option.
cli: fix git-colocated working copy on Windows 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.
2022-03-29 06:03:37 +00:00
### Fixed bugs
cli: fix crash when initializing workspace colocated with Git repo 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.
2022-03-28 13:46:21 +00:00
* Fixed crash on `jj init --git-repo=.` (it almost always crashed).
cli: fix git-colocated working copy on Windows 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.
2022-03-29 06:03:37 +00:00
* When sharing the working copy with a Git repo, the automatic importing and
exporting (sometimes?) didn't happen on Windows.
release: include the two recent no-op releases in the changelog I keep forgetting to update things while doing a release...
2022-03-17 06:01:42 +00:00
## [0.3.3] - 2022-03-16
No changes, only trying to get the automated build to work.
## [0.3.2] - 2022-03-16
No changes, only trying to get the automated build to work.
release: update release notes for 0.3.1 I forgot to do this when I bumped the version number.
2022-03-14 04:51:21 +00:00
## [0.3.1] - 2022-03-13
cli: expand `~` in `core.excludesFile`, don't crash when missing 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.
2022-03-13 15:14:01 +00:00
### Fixed bugs
changelog: copy formatting of links to issues from Cargo I thought I had seen our current formatting, i.e. `(#123)`, get auto-linked by GitHub, but it seems it doesn't. This patch therefore changes to use markdown links. I copied the style from Cargo (and Clippy).
2022-12-03 17:44:21 +00:00
- Fixed crash when `core.excludesFile` pointed to nonexistent file, and made
leading `~/` in that config expand to `$HOME/`
[#131](https://github.com/martinvonz/jj/issues/131)
cli: expand `~` in `core.excludesFile`, don't crash when missing 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.
2022-03-13 15:14:01 +00:00
release: add a changelog
2022-03-12 18:48:51 +00:00
## [0.3.0] - 2022-03-12
Last release before this changelog started.
Reference in a new issue Copy permalink