martinvonz/jj
1
1
Fork 0
mirror of https://github.com/martinvonz/jj.git synced 2024-11-10 14:16:24 +03:00
Code Issues Packages Projects Releases Wiki Activity
119cc88832
jj/CHANGELOG.md

971 lines
39 KiB
Markdown
Raw Normal View History

release: add a changelog
2022-03-12 21:48:51 +03: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]
Add jj diffs --stat option
2023-08-13 22:30:57 +03:00
* `jj diff --stat` has been implemented. It shows a histogram of the changes,
same as `git diff --stat`. Fixes [#2066](https://github.com/martinvonz/jj/issues/2066)
release: add a changelog
2022-03-12 21:48:51 +03:00
git: add --all-remotes to git fetch
2023-08-22 13:21:02 +03:00
* `jj git fetch --all-remotes` has been implemented. It fetches all remotes
instead of just the default remote
revset: remove redundant candidates argument from filter predicates
2022-10-25 16:08:11 +03:00
### Breaking changes
chore(rust): bump MSRV to 1.71.0 Summary: Let's be more aggressive about tracking the latest stable Rust release. There's little benefit to being conservative so early on, especially when no users seem to have faced any issue with upgrading, or strictly required an old Rust version. Right now, just lagging Rust by 1 major release probably seems fine. We're targeting 1.71.0 to get ahead of the curve, since 1.72.0 will likely release sometime before the next `jj` release. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I4e691b6ba63b5b9023a75ae0a6917672
2023-07-11 16:08:13 +03:00
* The minimum supported Rust version (MSRV) is now 1.71.0.
simple_op_store: serialize RefTarget in new format (breaks downgrades) This is breaking change. Old jj binary will panic if it sees a view saved by new jj. Alternatively, we can store both new and legacy data for backward compatibility.
2023-07-15 18:54:50 +03:00
* The storage format of branches, tags, and git refs has changed. Newly-stored
repository data will no longer be loadable by older binaries.
cli: warn when using `:` revset operator
2023-07-28 03:33:54 +03:00
* The `:` revset operator is deprecated. Use `::` instead. We plan to delete the
`:` form in jj 0.15+.
cli: replace `--allow-large-revsets` by use of `all:` prefix See the earlier commit introducing the `::` operator for reasoning.
2023-07-25 19:07:03 +03:00
* The `--allow-large-revsets` flag for `jj rebase` and `jj new` was replaced by
a `all:` before the revset. For example, use `jj rebase -d 'all:foo-'`
instead of `jj rebase --allow-large-revsets -d 'foo-'`.
rebase/new: make `--allow-large-revset` no longer also allow duplicates The `--allow-large-revset` option for `jj rebase` and `jj new` is used for allowing a single revset to resolve to more than one destination commit. It also means that duplicate commits between individual revsets are allowed (e.g. `jj rebase -d x -d 'x|y'`). I'm about to replace the first meaning of the flag by a revset function. I don't think it's worth keeping the flag only for the second meaning, so I'm just removing the feature instead. We can add it back under a different name (`--allow-duplicate-destinations`?) if people care about it.
2023-07-25 20:17:36 +03:00
* The `--allow-large-revsets` flag for `jj rebase` and `jj new` can no longer be
used for allowing duplicate destinations. Include the potential duplicates
cli: replace `--allow-large-revsets` by use of `all:` prefix See the earlier commit introducing the `::` operator for reasoning.
2023-07-25 19:07:03 +03:00
in a single expression instead (e.g. `jj new 'all:x|y'`).
rebase/new: make `--allow-large-revset` no longer also allow duplicates The `--allow-large-revset` option for `jj rebase` and `jj new` is used for allowing a single revset to resolve to more than one destination commit. It also means that duplicate commits between individual revsets are allowed (e.g. `jj rebase -d x -d 'x|y'`). I'm about to replace the first meaning of the flag by a revset function. I don't think it's worth keeping the flag only for the second meaning, so I'm just removing the feature instead. We can add it back under a different name (`--allow-duplicate-destinations`?) if people care about it.
2023-07-25 20:17:36 +03:00
config: Rename `push.branch-prefix` option to `git.push-branch-prefix` This is for consistency with other `git.` options. See also https://github.com/martinvonz/jj/pull/1962#discussion_r1282605185
2023-08-08 01:36:39 +03:00
* The `push.branch-prefix` option was renamed to `git.push-branch-prefix`.
configs: use Notepad as default editor on Windows
2023-08-10 18:50:25 +03:00
* The default editor on Windows is now `Notepad` instead of `pico`.
working_copy: don't snapshot new files larger than 1MiB by default
2023-06-29 01:10:19 +03:00
* `jj` will fail attempts to snapshot new files larger than 1MiB by default. This behavior
can be customized with the `snapshot.max-new-file-size` config option.
commits: use empty strings instead of placeholders for missing name or email This commit replaces the functions `UserSettings::user_name_placeholder()`` and `UserSettings::user_email_placeholder()` with `const` `&str`s to emphasize that the placeholder strings must not be changed to support commits without names or email addresses made before this change.
2023-08-17 00:10:54 +03:00
* Author and committer signatures now use empty strings to represent unset
templater: move empty signature placeholder to user template This patch also extracts format_detailed_signature() function to deduplicate the "show" template bits. The added placeholder templates aren't labeled as "empty". If needed, I think the whole template can be labeled as "empty" (or "empty_commit") just like "working_copy". Closes #2112
2023-08-26 09:08:22 +03:00
names and email addresses. The `author`/`committer` template keywords and
methods also return empty strings.
commits: use empty strings instead of placeholders for missing name or email This commit replaces the functions `UserSettings::user_name_placeholder()`` and `UserSettings::user_email_placeholder()` with `const` `&str`s to emphasize that the placeholder strings must not be changed to support commits without names or email addresses made before this change.
2023-08-17 00:10:54 +03:00
Older binaries may not warn user when attempting to `git push` commits
with such signatures.
revset: parse @ like operator (but without alias substitution) This is what I proposed in #2095. @ is now an operator to concatenate symbols. Unlike the other operators, lhs/rhs of @ is not a target of alias substitution. 'x' in 'x@y' doesn't look like a named variable, though it's technically possible to allow definition of an alias expanded to a symbol of specific remote or vice versa. This will probably apply to the kind:pattern syntax, where aliases are expanded due to the current implementation restriction. I've added a TODO comment about that.
2023-08-23 09:48:45 +03:00
* In revsets, the working-copy or remote symbols (such as `@`, `workspace_id@`,
and `branch@remote`) can no longer be quoted as a unit. If a workspace or
branch name contains whitespace, quote the name like `"branch name"@remote`.
Also, these symbols will not be resolved as revset aliases or function
parameters. For example, `author(foo@)` is now an error, and the revset alias
`'revset-aliases.foo@' = '@'` will be failed to parse.
working_copy: don't snapshot new files larger than 1MiB by default
2023-06-29 01:10:19 +03:00
revset: convert root symbol to function The idea is that we can fully eliminate special symbols that would otherwise shadow user branches, tags, or change ID prefixes. Closes #2095
2023-09-03 06:47:23 +03:00
* The `root` revset symbol has been converted to function `root()`.
revset: evaluate "..y" expression to "root()..y" This seems useful since the root commit is often uninteresting. It's also consistent with "x::y" in a way that the left operand defaults to "root()".
2023-09-05 02:38:28 +03:00
* The `..x` revset is now evaluated to `root()..x`, which means the root commit
is no longer included.
cli: make `jj git push` default to `-r 'remote_branches()..@'` The way `jj git push` without arguments chooses branches pointing to either `@` or `@-` is unusual and difficult to explain. Now that we have `-r`, we could instead default it to `-r '@-::@'`. However, I think it seems likely that users will want to push all local branches leading up to `@` from the closest remote branch. That's typically what I want. This patch changes the default to do that.
2023-08-21 23:11:40 +03:00
* `jj git push` will now push all branches in the range `remote_branches()..@`
instead of only branches pointing to `@` or `@-`.
git: prohibit creation of remote named "git" #1690
2023-08-19 08:01:49 +03:00
* It's no longer allowed to create a Git remote named "git". Use `jj git remote
rename` to rename the existing remote.
[#1690](https://github.com/martinvonz/jj/issues/1690)
release: release version 0.8.0 Thanks to everyone who's contributed!
2023-07-09 07:41:55 +03:00
### New features
cli: hide irrelevant information about root commit in default log templates I've extracted the `builtin_log_root` template for users to customize the default templates without fully overriding them, for example I would remove the change_id/commit_id for myself - and we discussed in Discord that leaving those makes sense for the user to be reminded/teached that the root commit has a change id made from z's.
2023-08-15 16:18:56 +03:00
* Default template for `jj log` now does not show irrelevant information
(timestamp, empty, message placeholder etc.) about the root commit.
templater: add `root` keyword Similar to other boolean flags, such as "working_copy" or "empty". We could test something like `"0000000000000000000000000000000000000000".contains(commit_id)` like I did for myself, but first of all this is ugly, and secondly the root commit id is not guaranteed to be 40 zeroes as custom backend implementations could have some other root.
2023-08-15 16:18:56 +03:00
* Commit templates now support the `root` keyword, which is `true` for the root
commit and `false` for every other commit.
Allow initializing with bare git repositories
2023-08-01 06:29:54 +03:00
* `jj init --git-repo` now works with bare repositories.
Allow editing non-existent configs Addresses #1571.
2023-07-13 00:08:58 +03:00
* `jj config edit --user` and `jj config set --user` will now pick a default
config location if no existing file is found, potentially creating parent directories.
revset_graph: group commits topologically The original idea was similar to Mercurial's "topo" sorting, but it was bad at handling merge-heavy history. In order to render merges of topic branches nicely, we need to prioritize branches at merge point, not at fork point. OTOH, we do also want to place unmerged branches as close to the fork point as possible. This commit implements the former requirement, and the latter will be addressed by the next commit. I think this is similar to Git's sorting logic described in the following blog post. In our case, the in-degree walk can be dumb since topological order is guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree integer value, which will be used in the next commit to resolve new heads as late as possible. https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve the index (or chronological) order. I tried beautify_graph() with prioritizing the @ commit, but the result seemed too aggressively reordered. Perhaps, for more complex history, beautify_graph() would produce a better result. For my wip branches (~30 branches, a couple of commits per branch), this works pretty well. #242
2023-07-16 13:47:46 +03:00
* `jj log` output is now topologically grouped.
[#242](https://github.com/martinvonz/jj/issues/242)
commands: Support the option of colocating a git repo with a jj repo This adds the new --colocate flag to `jj git clone`. ``` jj git clone --colocate https://github.com/foo/bar ``` is effectively equivalent to: ``` git clone https://github.com/foo/bar cd bar jj init --git-repo=. ```
2023-07-24 12:38:16 +03:00
* `jj git clone` now supports the `--colocate` flag to create the git repo
in the same directory as the jj repo.
cli: New `-changes-in` argument to `jj restore` + docs Also updates docstrings for `diffedit`, `abandon` in related ways. The changes are a bit too intertwined to comfortable split into a separate commit.
2023-02-20 11:45:23 +03:00
* `jj restore` gained a new option `--changes-in` to restore files
from a merge revision's parents. This undoes the changes that `jj diff -r`
would show.
cli: add option to generate textual diff by external command This is basic implementation. There's no config knob to enable the external diff command by default. It reuses the merge-tools table because that's how external diff/merge commands are currently configured. We might want to reorganize them in #1285. If you run "jj diff --tool meld", GUI diff will open and jj will wait for meld to quit. This also applies to "jj log -p". The "diff --tool gui" behavior is somewhat useful, but "log -p --tool gui" wouldn't. We might want some flag to mark the tool output can't be streamed. Another thing to consider is tools that can't generate directory diffs. Git executes ext-diff tool per file, but we don't. Difftastic can compare directories, and doing that should be more efficient since diffs can be computed in parallel (at the expense of unsorted output.) Closes #1886
2023-08-02 06:12:11 +03:00
* `jj diff`/`log` now supports `--tool <name>` option to generate diffs by
external program. For configuration, see [the documentation](docs/config.md).
[#1886](https://github.com/martinvonz/jj/issues/1886)
cli: New `-changes-in` argument to `jj restore` + docs Also updates docstrings for `diffedit`, `abandon` in related ways. The changes are a bit too intertwined to comfortable split into a separate commit.
2023-02-20 11:45:23 +03:00
merge_tools: Allow 3-pane diff editing As discussed in https://github.com/martinvonz/jj/discussions/1905#discussioncomment-6589673
2023-08-08 02:40:10 +03:00
* A new experimental diff editor `meld-3` is introduced that sets up Meld to
allow you to see both sides of the original diff while editing. This can be
used with `jj split`, `jj move -i`, etc.
cli: add "--limit N" option to log-like commands Copied from Mercurial. This isn't a revset predicate since our revset is conceptually unordered.
2023-08-10 12:14:54 +03:00
* `jj log`/`obslog`/`op log` now supports `--limit N` option to show the first
`N` entries.
configs: add the ability to disable paging via `ui.paginate`
2023-08-11 07:22:19 +03:00
* Added the `ui.paginate` option to enable/disable pager usage in commands
cli: Allow repeated `-m` options for multi-paragraph descriptions Emulates git's behavior: https://www.git-scm.com/docs/git-commit#Documentation/git-commit.txt--mltmsggt
2023-08-12 04:38:11 +03:00
* `jj checkout`/`jj describe`/`jj commit`/`jj new`/`jj squash` can take repeated
`-m/--message` arguments. Each passed message will be combined into paragraphs
(separated by a blank line)
cli: add support for setting default description That is, jj will use ui.default_description as a starting point when user is about to describe an empty change. I think it might be confusing to do this with -m / --stdin (violates WYSIWYG), so I'm only doing this when jj invokes an editor. Also, this could evolve into a proper template in the future instead of just plain text, to allow inheriting from parent change(s), for example. Partially addresses #1354.
2023-08-12 13:19:27 +03:00
* It is now possible to set a default description using the new
`ui.default-description` option, to use when describing changes with an empty
description.
cli: when splitting change without description, skip it on second part One use case for `jj split` is when creating a new commit from some of the changes in the working copy. If there's no description on the working-copy commit in that case, it seems better to not ask the user to provide one when they're splitting the commit either.
2023-08-15 19:35:45 +03:00
* `jj split` will now leave the description empty on the second part if the
description was empty on the input commit.
revset: add literal:"string" pattern syntax The syntax is slightly different from Mercurial. In Mercurial, a pattern must be quoted like "<kind>:<needle>". In JJ, <kind> is a separate parsing node, and it must not appear in a quoted string. This allows us to report unknown prefix as an error. There's another subtle behavior difference. In Mercurial, branch(unknown) is an error, whereas our branches(literal:unknown) is resolved to an empty set. I think erroring out doesn't make sense for JJ since branches() by default performs substring matching, so its behavior is more like a filter. The parser abuses DAG range syntax for now. It can be rewritten once we remove the deprecated x:y range syntax.
2023-08-16 12:41:21 +03:00
* `branches()`/`remote_branches()`/`author()`/`committer()`/`description()`
revset: rename literal:"" prefix to exact:"" Per discussion in #2107, I believe "exact" is preferred. We can also change the default to exact match, but it doesn't always make sense. Exact match would be useful for branches(), but not for description(). We could define default per predicate function, but I'm pretty sure I cannot remember which one is which.
2023-08-19 03:59:40 +03:00
revsets now support exact matching. For example, `branch(exact:main)`
selects the branch named "main", but not "maint". `description(exact:"")`
revset: add literal:"string" pattern syntax The syntax is slightly different from Mercurial. In Mercurial, a pattern must be quoted like "<kind>:<needle>". In JJ, <kind> is a separate parsing node, and it must not appear in a quoted string. This allows us to report unknown prefix as an error. There's another subtle behavior difference. In Mercurial, branch(unknown) is an error, whereas our branches(literal:unknown) is resolved to an empty set. I think erroring out doesn't make sense for JJ since branches() by default performs substring matching, so its behavior is more like a filter. The parser abuses DAG range syntax for now. It can be rewritten once we remove the deprecated x:y range syntax.
2023-08-16 12:41:21 +03:00
selects commits whose description is empty.
revset: rename literal:"" prefix to exact:"" Per discussion in #2107, I believe "exact" is preferred. We can also change the default to exact match, but it doesn't always make sense. Exact match would be useful for branches(), but not for description(). We could define default per predicate function, but I'm pretty sure I cannot remember which one is which.
2023-08-19 03:59:40 +03:00
* Revsets gained a new function `mine()` that aliases `author(exact:"your_email")`.
CHANGELOG: more precise description of `mine()`
2023-08-19 00:00:35 +03:00
revset: add 0-ary "::" and ".." operators as short for "all()" and "~root()" Suppose "x::y" is the operator that defaults to "root()::visible_heads()" respectively, "::" is identical to "all()". Since we've just changed the behavior of "..y", ".." is now "root()..visible_heads()" meaning "~root()".
2023-09-03 11:08:16 +03:00
* Added support for `::` and `..` revset operators with both left and right
operands omitted. These expressions are equivalent to `all()` and `~root()`
respectively.
Add UTC format for timestamp formats. Thanks to @rauljordan for these changes. Add tests for new UTC timestamp format Add documentation for timestamp utc Update CHANGELOG.md
2023-08-11 23:31:47 +03:00
* `jj log` timestamp format now accepts `.utc()` to convert a timestamp to UTC.
templates: Add more string methods Add starts_with/ends_with/remove_prefix/remove_suffix/substr methods to string when templating.
2023-08-22 21:40:51 +03:00
* templates now support additional string methods `.starts_with(x)`, `.ends_with(x)`
`.remove_prefix(x)`, `.remove_suffix(x)`, and `.substr(start, end)`.
Add UTC format for timestamp formats. Thanks to @rauljordan for these changes. Add tests for new UTC timestamp format Add documentation for timestamp utc Update CHANGELOG.md
2023-08-11 23:31:47 +03:00
commands: Implement `next` and `prev` This is a naive implementation, which cannot deal with multiple children or parents stemming from merges. Note: I gave each command separate a separate argument struct for extensibility. Fixes #878
2023-01-22 02:07:42 +03:00
* `jj next` and `jj prev` are added, these allow you to traverse the history
in a linear style. For people coming from Sapling and `git-branchles`
see [#2126](https://github.com/martinvonz/jj/issues/2126) for
further pending improvements.
release: release version 0.8.0 Thanks to everyone who's contributed!
2023-07-09 07:41:55 +03:00
### Fixed bugs
Fix .gitignore handling of ignored directories - Ignore .gitignore files from untracked directories - Do not allow un-ignoring files within ignored directories
2023-08-18 02:48:33 +03:00
* Fix issues related to .gitignore handling of untracked directories
[#2051](https://github.com/martinvonz/jj/issues/2051).
Allow editing user-specific config file outside of a repo This addresses #2054.
2023-08-13 03:38:46 +03:00
* `jj config set --user` and `jj config edit --user` can now be used outside of any repository.
git: add support for SSH authentication with ed25519 or ed25519-sk This makes it possible to use ed25519 and ed25519-sk keys by trying them one at a time. However, it still fails if one of them is password-protected; we don't try the next key in that case.
2023-08-08 20:51:42 +03:00
* SSH authentication could hang when ssh-agent couldn't be reached
git: only try to use ssh-agent once per connection As reported in #1970, SSH authentication would sometimes run into a loop where it repeatedly tries to use ssh-agent for authentication without making progess. The problem can be reproduced by simply removing `$SSH_AUTH_KEY` from your environment (and not having a Git credentials helper configured, I think). This seems to be a bug introduced by b104f8e154c21. That commit meant to make it so we attempt to use ssh-agent and fall back to using (password-less) keys after that. The problem is that `git2::Cred::ssh_key_from_agent()` just returns an object that will be used later for looking up the credentials from ssh-agent, so the call will not fail because ssh-agent is not reachable. This commit attempts to fix the problem by having the credentials callback attempt to use ssh-agent only once.
2023-08-08 07:30:23 +03:00
[#1970](https://github.com/martinvonz/jj/issues/1970)
cli: add support for setting default description That is, jj will use ui.default_description as a starting point when user is about to describe an empty change. I think it might be confusing to do this with -m / --stdin (violates WYSIWYG), so I'm only doing this when jj invokes an editor. Also, this could evolve into a proper template in the future instead of just plain text, to allow inheriting from parent change(s), for example. Partially addresses #1354.
2023-08-12 13:19:27 +03:00
git: add support for SSH authentication with ed25519 or ed25519-sk This makes it possible to use ed25519 and ed25519-sk keys by trying them one at a time. However, it still fails if one of them is password-protected; we don't try the next key in that case.
2023-08-08 20:51:42 +03:00
* SSH authentication can now use ed25519 and ed25519-sk keys. They still need
to be password-less.
git: only try to use ssh-agent once per connection As reported in #1970, SSH authentication would sometimes run into a loop where it repeatedly tries to use ssh-agent for authentication without making progess. The problem can be reproduced by simply removing `$SSH_AUTH_KEY` from your environment (and not having a Git credentials helper configured, I think). This seems to be a bug introduced by b104f8e154c21. That commit meant to make it so we attempt to use ssh-agent and fall back to using (password-less) keys after that. The problem is that `git2::Cred::ssh_key_from_agent()` just returns an object that will be used later for looking up the credentials from ssh-agent, so the call will not fail because ssh-agent is not reachable. This commit attempts to fix the problem by having the credentials callback attempt to use ssh-agent only once.
2023-08-08 07:30:23 +03:00
cli: detect .git symlink as a colocated workspace Maybe we could load GitBackend without resolving .git symlink, but that would introduce more subtle bugs. Instead, we calculate the expected Git workdir path from the canonical ".git" path. Fixes #2011
2023-08-10 03:11:17 +03:00
* Git repository managed by the repo tool can now be detected as a "colocated"
repository.
[#2011](https://github.com/martinvonz/jj/issues/2011)
release: release version 0.8.0 Thanks to everyone who's contributed!
2023-07-09 07:41:55 +03:00
## [0.8.0] - 2023-07-09
### Breaking changes
cargo: rename crates from `jujutsu`/`jujutsu-lib` to `jj-cli`/`jj-lib` Almost everyone calls the project "jj", and there seeems to be consensus that we should rename the crates. I originally wanted the crates to be called `jj` and `jj-lib`, but `jj` was already taken. `jj-cli` is probably at least as good for it anyway. Once we've published a 0.8.0 under the new names, we'll release 0.7.1 versions under the old names with pointers to the new crates names.
2023-06-28 17:12:40 +03:00
* The `jujutsu` and `jujutsu-lib` crates were renamed to `jj-cli` and `jj-lib`,
respectively.
templater: migrate op log to template language The outermost "op-log" label isn't moved to the default template. I think it belongs to the command's formatter rather than the template. Old bikeshedding items: - "current_head", "is_head", or "is_head_op" => renamed to "current_operation" - "templates.op-log" vs "templates.op_log" (the whole template is labeled as "op-log") => renamed to "op_log" - "template-aliases.'format_operation_duration(time_range)'" => renamed to 'format_time_range(time_range)'
2023-02-19 11:05:50 +03:00
* The `ui.oplog-relative-timestamps` option has been removed. Use the
`format_time_range()` template alias instead. For details, see
[the documentation](docs/config.md).
templater: require infix ++ operator to concatenate expressions This eliminates ambiguous parsing between "func()" and "expr ()". I chose "++" as template concatenation operator in case we want to add bit-wise negate operator. It's also easier to find/replace than "~".
2023-02-28 14:30:57 +03:00
* Implicit concatenation of template expressions has been disabled. Use
`++` operator, `concat()`, or `separate()` function instead.
Example: `description ++ "\n"`
git push: do not consider @- if @ has non-empty content or description
2023-03-05 23:27:03 +03:00
* `jj git push` will consider pushing the parent commit only when the
current commit has no content and no description, such as right after
a `jj squash`.
cargo: update MSRV to 1.64 We need 1.64 to bump `clap` to `4.1`. We don't really need to upgrade to that, but being on an older version causes minor confusions like #1393. Rust 1.64 is very close to 6 months old at this point.
2023-03-18 01:42:55 +03:00
* The minimum supported Rust version (MSRV) is now 1.64.0.
revset: split out no-args `head()` to `visible_heads()` The `heads()` revset function with one argument is the counterpart to `roots()`. Without arguments, it returns the visible heads in the repo, i.e. `heads(all())`. The two use cases are quite different, and I think it would be good to clarify that the no-arg form returns the visible heads, so let's split that out to a new `visible_heads()` function.
2023-03-28 09:13:31 +03:00
* The `heads()` revset function was split up into two functions. `heads()`
without arguments is now called `visible_heads()`. `heads()` with one argument
is unchanged.
cli: rename `ui.default-revset` to `revsets.log` I plan to add `revsets.short-prefixes` and `revsets.immutable` soon, and I think `[revsets]` seems like reasonable place to put them. It seems consistent with our `[templates]` section. However, it also suffers from the same problem as that section, which is that the difference between `[templates]` and `[template-aliases]` is not clear. We can decide about about templates and revsets later.
2023-05-11 09:26:23 +03:00
* The `ui.default-revset` config was renamed to `revsets.log`.
cli: make `jj sparse --list` a subcommand `jj sparse` is a bit different from other commands in that its `jj sparse --list` is practically a separate command. Let's make it an actual subcommand for consistency, and so we can more cleanly add additional flags for `jj sparse list` in the future. I moved all the other arguments to `jj sparse set`. I'm not sure if `jj sparse set --reset` would have been better as `jj sparse reset`, but it is technically just updating the sparse patterns just like the other arguments (`--clear`, `--add` , `--remove`).
2023-05-22 00:07:54 +03:00
* The `jj sparse` command was split up into `jj sparse list` and
`jj sparse set`.
changelog: removing the `jj hide` alias is a breaking change
2023-06-03 19:47:43 +03:00
* `jj hide` (alias for `jj abandon`) is no longer available. Use `jj abandon`
instead.
changelog: consider renamed `jj debug` commands a breaking change I think I originally didn't consider changing debug commands as a breaking change, but it's better to be conservative.
2023-06-04 05:07:35 +03:00
* `jj debug completion`, `jj debug mangen` and `jj debug config-schema` have
been moved from `jj debug` to `jj util`.
revsets: stop `jj` parsing `br` as a git_ref `refs/heads/br` Use `br@git` instead. Before, if there is not a local branch `br`, jj tried to resolve it as a git ref `refs/heads/br`. Unchanged from before, `br` can still be resolved as a tag `refs/tag/br`.
2023-06-12 21:59:15 +03:00
* `jj` will no longer parse `br` as a git_ref `refs/heads/br` when a branch `br`
does not exist but the git_ref does (this is rare). Use `br@git` instead.
git: consistently ignore unrelated refs on fetch() Since "jj git fetch --branch '*'" doesn't import unrelated remote and local refs, "jj git fetch" shouldn't do either.
2023-07-04 10:18:17 +03:00
* `jj git fetch` will no longer import unrelated branches from the underlying
Git repo.
release: release version 0.7.0 It's been about 10 weeks and 730 commits since 0.6.0, compared to about 7 weeks and 350 commits between 0.5.0 and 0.6.0, so it's time for a new release. There's been significant user-visible changes and code-quality improvements. Thanks, everyone!
2023-02-16 20:26:40 +03:00
### New features
git push: add --deleted option
2023-02-19 15:08:24 +03:00
* `jj git push --deleted` will remove all locally deleted branches from the remote.
cmd: Make `jj restore` work if `@` is a merge commit To be clear, this applies to `jj restore` without any arguments. Fixes #1228
2023-02-10 08:48:47 +03:00
* `jj restore` without `--from` works correctly even if `@` is a merge
commit.
cmd: Allow multiple `-b` for `jj rebase` This also makes `rebase_branch` reuse `rebase_descendants`. This addresses a portion of #1158
2023-02-19 06:31:48 +03:00
* `jj rebase` now accepts multiple `-s` and `-b` arguments. Revsets with
multiple commits are allowed with `--allow-large-revsets`.
cmd: Allow multiple `-s` for `jj rebase` This addresses a portion of #1158 One application (not the prettiest, but useful until we have `jj sync`): jj rebase -s oldmain+~:main -d main -L
2023-02-19 06:31:48 +03:00
cmd: `--branch` option for `git fetch`. Thanks to @samueltardieu for noticing a subtle bug in the refspecs, providing the fix, as well as the two `conflicting_branches` tests.
2023-01-13 01:53:26 +03:00
* `jj git fetch` now supports a `--branch` argument to fetch some of the
branches only.
feat(config): add `jj config get` for scripting The motivating use-case was this `jj signoff` script: https://gist.github.com/thoughtpolice/8f2fd36ae17cd11b8e7bd93a70e31ad6 Which includes lines like this: ```sh NAME=$(jj config list user.name | awk '{split($0, a, "="); print a[2];}' | tr -d '"') MAIL=$(jj config list user.email | awk '{split($0, a, "="); print a[2];}' | tr -d '"') ``` There is no reason that we should have to clumsily parse out the config values. This `jj config get` command supports scripting use-cases like this.
2023-06-23 21:55:11 +03:00
* `jj config get` command allows retrieving config values for use in scripting.
Implement "config set" subcommand Uses toml_edit to support simple config edits like: jj config set --repo user.email "somebody@example.com"
2023-01-15 07:23:44 +03:00
* `jj config set` command allows simple config edits like
`jj config set --repo user.email "somebody@example.com"`
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 07:10:02 +03:00
* Added `ui.log-word-wrap` option to wrap `jj log`/`obslog`/`op log` content
based on terminal width. [#1043](https://github.com/martinvonz/jj/issues/1043)
Switch graph node to use `◉` for commit instead of `●` This follows up on 5c703aeb0397b560a383bdd57a87235834074b64. The only reason for this change is that, subjectively, the result looks better to me. I'm not sure why, but I couldn't get used to the old symbol in spite of its seeming reasonableness. It felt really bold and heavy. If people agree, we can wait until we need to update the screenshots for some other reason before merging this. Sorry I didn't figure this out while the discussion about the referenced commit was going on. I'm not 100% certain how many fonts support each symbol. Please try it out and let me know if it doesn't work for you. Compare after: ![image](https://user-images.githubusercontent.com/4123047/229251383-563b889d-7233-42e2-a3c5-bf9368a4d1fd.png) and before: ![image](https://user-images.githubusercontent.com/4123047/229251695-7fd0ff2c-2832-4262-ade5-5120288cccdf.png)
2023-03-15 06:37:56 +03:00
* Nodes in the (text-based) graphical log output now use a `◉` symbol instead
cmd: when a single remote is defined, default to it for git fetch/push A simple quick implementation of what I've suggested on discord
2023-04-04 16:34:12 +03:00
of the letter `o`. The ASCII-based graph styles still use `o`.
cli: replace `o` as graph node by `●` when using unicode graph @joyously found `o` confusing because it's a valid change id prefix. I don't have much preference, but `●` seems fine. The "ascii", "ascii-large", and "legacy" graph styles still use "o". I didn't change `@` since it seems useful to have that match the symbol used on the CLI. I don't think we want to have users do something like `jj co ◎-`.
2023-03-11 10:10:31 +03:00
cli: show diff summary as two states instead of transition By using one letter for the path type before and one letter for path type after, we can encode much more information than just the current 'M'/'A'/'R'. In particular, we can indicate new and resolved conflicts. The color still encodes the same information as before. The output looks a bit weird after many years of using `hg status`. It's a bit more similar to the `git status -s` format with one letter for the index and one with the working copy. Will we get used to it and find it useful?
2021-09-16 08:46:54 +03:00
* Commands that accept a diff format (`jj diff`, `jj interdiff`, `jj show`,
`jj log`, and `jj obslog`) now accept `--types` to show only the type of file
before and after.
cli: add `jj describe --reset-author` I think requests to reset the author came up twice in the last week, so let's just add support for it. I copied git's behavior of resetting the name, email, and timestamp. The flag name is also from git.
2023-03-18 08:34:25 +03:00
* `jj describe` now supports `--reset-author` for resetting a commit's author
cli: add `jj describe --no-edit` to not open editor
2023-03-18 09:33:48 +03:00
to the configured user. `jj describe` also gained a `--no-edit` option to
avoid opening the editor.
cli: add `jj describe --reset-author` I think requests to reset the author came up twice in the last week, so let's just add support for it. I copied git's behavior of resetting the name, email, and timestamp. The flag name is also from git.
2023-03-18 08:34:25 +03:00
revset: add latest(candidates, count) predicate This serves the role of limit() in Mercurial. Since revsets in JJ is (conceptually) an unordered set, a "limit" predicate should define its ordering criteria. That's why the added predicate is named as "latest". Closes #1110
2023-03-25 06:14:26 +03:00
* Added `latest(x[, n])` revset function to select the latest `n` commits.
revset: add a revset function for finding commits with conflicts This adds `conflict()` revset that selects commits with conflicts. We may want to extend it later to consider only conflicts at certain paths.
2023-04-05 06:05:51 +03:00
* Added `conflict()` revset function to select commits with conflicts.
`squash`/`amend`: Add `-m` argument to set description This prevents an editor opening, and is useful in scripts/tests.
2023-04-04 01:16:23 +03:00
* `jj squash` AKA `jj amend` now accepts a `--message` option to set the
description of the squashed commit on the command-line.
cli: include total downloaded size in progress output With this change, the output looks like this: ``` 3% 165.9 Mi at 13.4 MiB/s [█▋ ] ``` Closes #1483.
2023-04-05 15:26:47 +03:00
* The progress display on `jj git clone/fetch` now includes the downloaded size.
formatter: allow using "default" terminal color The "default" color resets the terminal color to default.
2023-04-08 09:25:30 +03:00
* The formatter now supports a "default" color that can override another color
defined by a parent style.
Templater: label hidden commits (aka abandoned commits) Looks like "change_id normal" + color. Picture for `jj obslog`: https://user-images.githubusercontent.com/4123047/230708271-4108cf5f-255d-419e-bd3e-fc97dc8b8660.png This should also be occasionally be useful for e.g. `jj log commit_id`. I also considered the wording `(Was change_id)` or `change_id (old)`, `change_id (obs)`.
2023-04-08 04:28:16 +03:00
* `jj obslog` and `jj log` now show abandoned commits as hidden.
cli: allow `jj git push --change xyz --branch foo` This was pretty simple. I simplified a bit by making the transaction description mention only branches, not changes. It still mentions the branches created for the changes, however. Also, since the operation "tags" contain the full command line, I think it'll still be relatively easy for the user to understand what the operation was about.
2023-06-03 09:24:28 +03:00
* `jj git fetch` and `jj git push` will now use the single defined remote even
if it is not named "origin".
cli: add `jj git push -r` for pushing branches pointing to revset I think I will find this useful in at least two cases: 1. When you already have a branch pointing to some commit, it's easier to do `jj git push -r xyz` than `jj git push --branch push-xyzxyzyxzxyz`. 2. When you have a stack of changes, it's useful to be able to push all of them at once. I think we should also update the default behavior of `jj git push` to be `jj git push -r 'remote_branches()..@'` or something like that. That removes the ugliness of having a default behavior that the user can't reproduce using flags. I'll leave that change for a separate PR.
2023-06-03 08:39:33 +03:00
* `jj git push` now accepts `--branch` and `--change` arguments together.
* `jj git push` now accepts a `-r/--revisions` flag to specify revisions to
push. All branches pointing to any of the specified revisions will be pushed.
The flag can be used together with `--branch` and `--change`.
cmd: when a single remote is defined, default to it for git fetch/push A simple quick implementation of what I've suggested on discord
2023-04-04 16:34:12 +03:00
cli: default to log when no subcommand is provided This is a convenience optimization to improve the default user experience, since `jj log` is a frequently run command. Accessing the help information explicitly still follows normal CLI conventions, and instructions are displayed appropriately if the user happens to make a mistake. Discoverability should not be adversely harmed. Note that this behavior mirrors what Sapling does [2], where `sl` will display the smartlog by default. [1] https://github.com/clap-rs/clap/issues/975 [2] https://sapling-scm.com/docs/overview/smartlog
2023-04-14 04:49:35 +03:00
* `jj` with no subcommand now defaults to `jj log` instead of showing help. This
command can be overridden by setting `ui.default-command`.
cli: use a unique file extension for description tempfiles Establishing a unique file extension for the temporary files created via `jj describe` helps to ensure that text editors can recognize the filetype and alter settings accordingly. This will open the door for an improved user experience, and allow for setting things like the appropriate text-width/rulers, syntax highlighting of the diff summary (see Git's commit tree-sitter grammer [1]), easy toggling of the `JJ:` comment lines, etc. I examined the behavior of filetype detection across a number of common text editors, and the most universally-support mechanism was to have a unique extension that does not include any periods. Meaning that namespacing via something like `.jj.txt` instead, won't always be detected due to inconsistent matching prioritization across editors. It also makes sense to assume that we may want other Jujutsu-specific filetypes in the future. The filename prefix has also been switched to be `editor-` for clarity, as well as to ease matching a glob-pattern if we ever need to garbage collect leftover tempfiles. This structure is similar to what Mercurial and Sapling do as well. [1] https://github.com/the-mikedavis/tree-sitter-git-commit
2023-04-18 17:59:24 +03:00
* Description tempfiles created via `jj describe` now have the file extension
`.jjdescription` to help external tooling detect a unique filetype.
cli: allow resolving shorter ids within a configured revset This adds a config called `revsets.short-prefixes`, which lets the user specify a revset in which to disambiguate otherwise ambiguous change/commit ids. It defaults to the value of `revsets.log`. I made it so you can disable the feature by setting `revsets.short-prefixes = ""`. I don't like that the default value (using `revsets.log`) cannot be configured explicitly by the user. That will be addressed if we decide to merge the `[revsets]` and `[revset-aliases]` sections some day.
2023-05-06 03:12:08 +03:00
* The shortest unique change ID prefixes and commit ID prefixes in `jj log` are
now shorter within the default log revset. You can override the default by
setting the `revsets.short-prefixes` config to a different revset.
cmd: have `jj branch list` report git-tracking (`@git`) branches This doesn't change the way @git branches are stored in `git_refs` as opposed to inside `BranchTarget` like normal remote-tracking branches. There are subtle differences in behavior with e.g. `jj branch forget` and I'm not sure how easy it is to rewrite `jj git import/export` to support a different way of storage. I've decided to call these "local-git tracking branches" since they track branches in the local git repository. "local git-tracking" branches sounds a bit more natural, but these could be confused with there are no remote git-tracking branches. If one had the idea these might exist, they would be confused with remote-tracking branches in the local git repo. This addresses a portion of #1666
2023-06-11 07:44:48 +03:00
* The last seen state of branches in the underlying git repo is now presented by
templater: include pseudo @git targets in branches keyword #1666
2023-07-07 19:49:28 +03:00
`jj branch list`/`jj log` as a remote called `git` (e.g. `main@git`). They can
also be referenced in revsets. Such branches exist in colocated repos or if
you use `jj git export`.
cmd: have `jj branch list` report git-tracking (`@git`) branches This doesn't change the way @git branches are stored in `git_refs` as opposed to inside `BranchTarget` like normal remote-tracking branches. There are subtle differences in behavior with e.g. `jj branch forget` and I'm not sure how easy it is to rewrite `jj git import/export` to support a different way of storage. I've decided to call these "local-git tracking branches" since they track branches in the local git repository. "local git-tracking" branches sounds a bit more natural, but these could be confused with there are no remote git-tracking branches. If one had the idea these might exist, they would be confused with remote-tracking branches in the local git repo. This addresses a portion of #1666
2023-06-11 07:44:48 +03:00
cli: new `jj chmod` command to set executable bit
2023-06-12 22:51:56 +03:00
* The new `jj chmod` command allows setting or removing the executable bit on
paths. Unlike the POSIX `chmod`, it works on Windows, on conflicted files, and
on arbitrary revisions. Bits other than the executable bit are not planned to
be supported.
add --edit option to `jj sparse set`
2023-06-06 08:32:11 +03:00
* `jj sparse set` now accepts an `--edit` flag which brings up the `$EDITOR` to
edit sparse patterns.
cli: add revset filter to "branch list" Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches #1136. The query matches against local targets only. This means there's no way to select deleted/forgotten branches by -r option. If we add a default revset configuration, we'll need some way to turn the default off.
2023-06-28 05:53:01 +03:00
* `jj branch list` can now be filtered by revset.
docs(fsmonitor): add filesystem monitor/Watchman documentation
2023-07-08 12:23:09 +03:00
* Initial support for the Watchman filesystem monitor. Set
`core.fsmonitor = "watchman"` in your repo to enable.
release: release version 0.7.0 It's been about 10 weeks and 730 commits since 0.6.0, compared to about 7 weeks and 350 commits between 0.5.0 and 0.6.0, so it's time for a new release. There's been significant user-visible changes and code-quality improvements. Thanks, everyone!
2023-02-16 20:26:40 +03:00
### Fixed bugs
conflicts: replace missing files by empty in materialized conflict When we materialize modify/delete conflicts, we currently don't include any context lines. That's because modify/delete conflicts have only two sides, so there's no common base to compare to. Hunks that are unchanged on the "modify" side are therefore not considered conflicting, and since they they don't contribute new changes, they're simply skipped (here: https://github.com/martinvonz/jj/blob/3dfedf581458f88982289f58db884bc65f1e635b/lib/src/files.rs#L228-L230). It seems more useful to instead pretend that the missing side is an empty file. That way we'll get a conflict in the entire file. We can still decide later to make e.g. `jj resolve` prompt the user on modify/delete conflicts just like `hg resolve` does (or maybe it actually happens earlier there, I don't remember). Closes #1244.
2023-02-17 21:05:47 +03:00
* Modify/delete conflicts now include context lines
[#1244](https://github.com/martinvonz/jj/issues/1244).
conflicts: fix bug when modifying modify/delete conflicts Currently, if the user modifies a modify/delete conflict, we always consider the result resolved. That happens because we materialize the missing side of the conflict as an empty string but when we parse the conflict, we expect only the number of sides in the input conflict. For example, if the input is a regular modify/delete conflict with one remove and one add, the materialized markers will have one remove and two adds (one of them empty), but when we try to parse it, we expect one remove and only one add. When we fail to parse it, we consider it resolved. This commit fixes the bug by using `conflicts::Conflict<Option<TreeValue>>` and keeping track of which sides were supposed to be empty. We could have fixed the bug without switching to `conflicts::Conflict`, but we want to switch anyway, and the fix happens naturally when switching.
2023-05-31 21:02:23 +03:00
* It is now possible to modify either side of a modify/delete conflict (any
change used to be considered a resolution).
conflicts: preserve order of adds in materialized conflict We write conflict to the working copy by materializing them as conflict markers in a file. When the file has been modified (or just the mtime has changed), we parse the markers to reconstruct the conflict. For example, let's say we see this conflict marker: ``` <<<<<<< +++++++ b %%%%%%% -a +c >>>>>>> ``` Then we will create a hunk with ["a"] as removed and ["b", "c"] as added. Now, since commit b84be06c0822, when we materialize conflicts, we minimize the diff part of the marker (the `%%%%%%%` part). The problem is that that minimization may result in a different order of the positive conflict terms. That's particularly bad because we do the minimization per hunk, so we can end up reconstructing an input that never existed. This commit fixes the bug by only considering the next add and the one after that, and emitting either only the first with `%%%%%%%`, or both of them, with the first one in `++++++++` and the second one in `%%%%%%%`. Note that the recent fix to add context to modify/delete conflicts means that when we parse modified such conflicts, we'll always consider them resolved, since the expected adds/removes we pass will not match what's actually in the file. That doesn't seem so bad, and it's not obvious what the fix should be, so I'll leave that for later.
2023-02-18 09:29:30 +03:00
* Fixed a bug that could get partially resolved conflicts to be interpreted
incorrectly.
git_fetch: when removing a remote branch, remove git ref as well
2023-02-24 20:24:48 +03:00
* `jj git fetch`: when re-adding a remote repository that had been previously
removed, in some situations the remote branches were not recreated.
git remote rename: rename git refs as well
2023-02-25 12:51:19 +03:00
* `jj git remote rename`: the git remote references were not rewritten with
the new name. If a new remote with the old name and containing the same
branches was added, the remote branches may not be recreated in some cases.
cli: snapshot stale working copy before updating Since there's no easy API to snapshot the stale working copy without releasing the lock, we have to compare the tree ids after reacquiring the lock. We could instead manually snapshot and rebase the working-copy commit, but that would require more copy-paste codes. Closes #1310
2023-02-26 14:52:06 +03:00
* `jj workspace update-stale` now snapshots the working-copy changes before
updating to the new working-copy commit.
cmd: prohibit creating branches at the root commit Such branches lead to confusing errors on git expoert or push.
2023-04-04 05:02:12 +03:00
* It is no longer allowed to create branches at the root commit.
git: on external HEAD move, do not abandon old branch The current behavior was introduced by 20eb9ecec10f "git: don't abandon HEAD commit when it loses a branch." While the change made HEAD mutation behavior more consistent with a plain ref operation, HEAD can also move on checkout, and checkout shouldn't be considered a history rewriting operation. I'm not saying the new behavior is always correct, but I think it's safer than losing old HEAD branch. I also think this change will help if we want to extract HEAD management function from git::import_refs(). Fixes #1042.
2023-05-10 13:10:40 +03:00
* `git checkout` (without using `jj`) in colocated repo no longer abandons
the previously checked-out anonymous branch.
[#1042](https://github.com/martinvonz/jj/issues/1042).
git.rs: properly abandon commits from moved/deleted branches on remote (#864) This bug concerns the way `import_refs` that gets called by `fetch` computes the heads that should be visible after the import. Previously, the list of such heads was computed *before* local branches were updated based on changes to the remote branches. So, commits that should have been abandoned based on this update of the local branches weren't properly abandoned. Now, `import_refs` tracks the heads that need to be visible because of some ref in a mapping keyed by the ref. If the ref moves or is deleted, the corresponding heads are updated. Fixes #864
2023-05-08 22:54:37 +03:00
* `jj git fetch` in a colocated repo now abandons branches deleted on the
remote, just like in a non-colocated repo.
[#864](https://github.com/martinvonz/jj/issues/864)
git fetch: do a `git export` of deleted branches before fetch
2023-06-30 05:20:00 +03:00
* `jj git fetch` can now fetch forgotten branches even if they didn't move on
the remote.
[#1714](https://github.com/martinvonz/jj/pull/1714)
[#1771](https://github.com/martinvonz/jj/pull/1771)
`branch forget`: allow forgetting deleted branches Partially fixes #1537
2023-06-24 07:48:48 +03:00
* It is now possible to `jj branch forget` deleted branches.
[#1537](https://github.com/martinvonz/jj/issues/1537)
changelog: mention fixes for #924 and #1608 (racy change id / snapshot)
2023-06-26 07:59:18 +03:00
* Fixed race condition when assigning change id to Git commit. If you've
already had unreachable change ids, run `jj debug reindex`.
[#924](https://github.com/martinvonz/jj/issues/924)
* Fixed false divergence on racy working-copy snapshots.
[#697](https://github.com/martinvonz/jj/issues/697),
[#1608](https://github.com/martinvonz/jj/issues/1608)
undo: preserve git-tracking refs in colocated repos by default
2023-06-01 06:55:46 +03:00
* In colocated repos, a bug causing conflicts when undoing branch moves (#922)
has been fixed. Some surprising behaviors related to undoing `jj git push` or
`jj git fetch` remain.
release: release version 0.8.0 Thanks to everyone who's contributed!
2023-07-09 07:41:55 +03:00
### Contributors
Thanks to the people who made this release happen!
* Aaron Bull Schaefer (@elasticdog)
* Anton Bulakh (@necauqua)
* Austin Seipp (@thoughtpolice)
* Benjamin Saunders (@Ralith)
* B Wilson (@xelxebar)
* Christophe Poucet (@poucet)
* David Barnett (@dbarnett)
* Glen Choo (@chooglen)
* Grégoire Geis (@71)
* Ilya Grigoriev (@ilyagr)
* Isabella Basso (@isinyaaa)
* Kevin Liao (@kevincliao)
* Martin von Zweigbergk (@martinvonz)
changelog: add @mlcui-google as contributor to 0.8.0 @mlcui-google made their first contribution after I drafted the release notes for 0.8.0 and I forgot to update the release notes before merging the PR.
2023-07-16 23:48:37 +03:00
* mlcui (@mlcui-google)
release: release version 0.8.0 Thanks to everyone who's contributed!
2023-07-09 07:41:55 +03:00
* Samuel Tardieu (@samueltardieu)
* Tal Pressman (@talpr)
* Vamsi Avula (@avamsi)
* Waleed Khan (@arxanas)
* Yuya Nishihara (@yuja)
release: release version 0.7.0 It's been about 10 weeks and 730 commits since 0.6.0, compared to about 7 weeks and 350 commits between 0.5.0 and 0.6.0, so it's time for a new release. There's been significant user-visible changes and code-quality improvements. Thanks, everyone!
2023-02-16 20:26:40 +03:00
## [0.7.0] - 2023-02-16
### Breaking changes
Update MSRV to 1.61 This is needed for compatibility with the sapling dag crate.
2023-01-19 07:54:19 +03:00
* The minimum supported Rust version (MSRV) is now 1.61.0.
Rename `jj touchup` to `jj diffedit`
2022-12-18 06:56:21 +03:00
* The `jj touchup` command was renamed to `jj diffedit`.
cmd: Remove the `-i` option to `jj restore`. It is superceded by the new options to the `jj diffedit` command.
2022-12-21 04:36:51 +03:00
* The `-i` option to `jj restore` was removed in favor of new `--from`/`--to`
options to `jj diffedit`.
`jj log`: Replace divergent label with ?? and red color This follows up on a [discussion] in a previous PR #941. [discussion]: https://github.com/martinvonz/jj/pull/941#issuecomment-1363551162 Screenshot: https://user-images.githubusercontent.com/4123047/209286340-bb83df2d-4020-4608-9755-d965477799c3.png
2023-01-07 04:49:31 +03:00
* To report the situation when a change id corresponds to multiple visible
commits, `jj log` now prints the change id in red and puts `??` after it.
Previously, it printed the word "divergent".
log: add (empty) in front of an empty commit description
2023-01-14 13:43:23 +03:00
* `jj log` prefixes commit descriptions with "(empty)" when they contain no
change compared to their parents.
templater: display both name and email by author/committer keywords This is an example of labeled output of structured value types. I think "{name} <{email}>" is a good default formatting, but I should note that the signature also contains timestamp field.
2023-01-22 15:16:52 +03:00
* The `author`/`committer` templates now display both name and email. Use
`author.name()`/`committer.name()` to extract the name.
git: allow conflicts in "HEAD@git" Git's HEAD ref is similar to other refs and can logically have conflicts just like the other refs in `git_refs`. As with the other refs, it can happen if you run concurrent commands importing two different updates from Git. So let's treat `git_head` the same as `git_refs` by making it an `Option<RefTarget>`.
2022-12-17 20:34:09 +03:00
* Storage of the "HEAD@git" reference changed and can now have conflicts.
Operations written by a new `jj` binary will have a "HEAD@git" reference that
is not visible to older binaries.
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 12:17:46 +03:00
* The `description` template keyword is now empty if no description set.
Use `if(description, description, "(no description set)\n")` to get back
the previous behavior.
config: rename [template] section to [templates], drop .graph suffix This should be more consistent with the other tables.
2023-02-14 17:55:30 +03:00
* The `template.log.graph` and `template.commit_summary` config keys were
renamed to `templates.log` and `templates.commit_summary` respectively.
* If a custom `templates.log` template is set, working-copy commit will
cli: use label() to highlight "working_copy" commit in log template I think this is a proper way to label the working-copy commit. This also fixes "jj obslog" output, but I don't think anyone would care.
2023-02-03 06:49:40 +03:00
no longer be highlighted automatically. Wrap your template with
`label(if(current_working_copy, "working_copy"), ...)` to label the
working-copy entry.
Rename `ui.relative-timestamps` to `ui.oplog-relative-timestamps`
2023-02-16 06:26:31 +03:00
* The `ui.relative-timestamps` option has been removed. Use the
`format_timestamp()` template alias instead. For details on showing relative
timestamps in `jj log` and `jj show`, see [the documentation](docs/config.md).
config: migrate log/show timestamp format away from config knob Since oplog still relies on ui.relative-timestamps, this config key isn't removed.
2023-02-15 13:49:10 +03:00
Rename `ui.relative-timestamps` to `ui.oplog-relative-timestamps`
2023-02-16 06:26:31 +03:00
* `jj op log` now shows relative timestamps by default. To disable, set
`ui.oplog-relative-timestamps` to `false`.
Make `ui.relative-timestamps` default to true This seems like a better default for `jj op log`, which is now the only thing this option affects.
2023-02-16 06:19:41 +03:00
cli: rename `--no-commit-working-copy` to `--ignore-working-copy` We have moved from saying "committing the working copy" towards saying "snapshotting the working copy". More importantly, the option also means that we don't update the working copy at the end. I went with the `--ignore-working-copy` name suggested by Ilya. I also updated the documentation of the option.
2023-02-03 02:11:18 +03:00
* The global `--no-commit-working-copy` is now called `--ignore-working-copy`.
cli: rename `diff.format` to `ui.diff.format` I felt that the config is too narrow to have it's own top-level [diff] section, and I couldn't think of another good place to have it. I'm happy to hear other suggestions.
2023-02-06 09:42:27 +03:00
* The `diff.format` config option is now called `ui.diff.format`. The old name
is still supported for now.
cli: expand $left/$right parameters in merge-tools.<name>.edit-args And set edit_args = ["$left", "$right"] by default.
2023-02-06 13:38:51 +03:00
* `merge-tools.<name>.edit-args` now requires `$left`/`$right` parameters.
The default is `edit-args = ["$left", "$right"]`.
cli: delete builtin `update/up` aliases These don't seem used much, and maybe we (or a customized build) will want to use the name in the future.
2023-02-10 18:52:14 +03:00
* The builtin `jj update` and `jj up` aliases for `jj checkout` have been
deleted.
cli: use reverse-alphabet hex for branch name in `jj git push --change`
2023-02-12 22:49:05 +03:00
* Change IDs are now rendered using letters from the end of the alphabet (from
'z' through 'k') instead of the usual hex digits ('0' through '9' and 'a'
through 'f'). This is to clarify the distinction between change IDs and commit
IDs, and to allow more efficient lookup of unique prefixes. This change
doesn't affect the storage format; existing repositories will remain usable.
templater: use reverse-alphabet hex for change ids
2023-02-12 23:07:28 +03:00
release: release version 0.6.0 Lots of new features and important bugfixes. Thanks, everyone!
2022-12-05 19:38:47 +03:00
### New features
cli: use committer timestamp instead of author timestamp in log output The author timestamp is rarely useful (in my experience). The committer timestamp, on the other hand, can be useful for understanding when a change was most recently modified. IIRC, I originally picked the author timestamp to match the email (which is the author's), but it's probably not confusing to use the author email and the committer timestamp. I suspect few users will even reflect on it.
2022-12-15 01:33:00 +03:00
* The default log format now uses the committer timestamp instead of the author
timestamp.
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 15:24:24 +03:00
* `jj log --summary --patch` now shows both summary and diff outputs.
Allow `jj git push` to push multiple branches/changes at once Also creates short arg `-b` for `--branch`.
2022-12-18 01:31:12 +03:00
* `jj git push` now accepts multiple `--branch`/`--change` arguments
Add a `config edit` command to open jj config in editor Part of #531 to define the overall `config` command.
2023-01-05 07:55:20 +03:00
* `jj config list` command prints values from config and `config edit` opens
the config in an editor.
Add a "config" command with "get" and "list" subcommands Partially fixes #531.
2022-12-13 09:22:08 +03:00
Add "jj debug config-schema" command to output JSON schema Extends TOML/JSON schema changes from #966 to allow jj to output the schema directly. Context in #879.
2023-01-03 05:26:59 +03:00
* `jj debug config-schema` command prints out JSON schema for the jj TOML config
file format.
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 03:34:56 +03:00
* `jj resolve --list` can now describe the complexity of conflicts.
`jj resolve`: List remaining conflicts (if any) on success This can be prevented by the new `--quiet` option.
2022-12-24 04:57:10 +03:00
* `jj resolve` now notifies the user of remaining conflicts, if any, on success.
This can be prevented by the new `--quiet` option.
cli: load configs from .jj/repo/config.toml Since per-repo config may contain CLI settings, it must be visible to CLI. Therefore, UserSettings::with_repo() -> RepoSettings isn't used, and its implementation is nullified by this commit. #616
2023-01-02 08:18:38 +03:00
* Per-repository configuration is now read from `.jj/repo/config.toml`.
formatter: add support for underlined text
2023-01-10 05:59:21 +03:00
* Background colors, bold text, and underlining are now supported. You can set
e.g. `color.error = { bg = "red", bold = true, underline = true }` in your
`~/.jjconfig.toml`.
formatter: add support for setting background color
2023-01-07 20:34:15 +03:00
template: add "empty" template item
2023-01-14 13:43:23 +03:00
* The `empty` condition in templates is true when the commit makes no change to
the three compared to its parents.
let branches and remote_branches revset functions take needles as arguments - branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring - remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
2023-01-12 13:01:35 +03:00
* `branches([needle])` revset function now takes `needle` as an optional
argument and matches just the branches whose name contains `needle`.
* `remote_branches([branch_needle[, remote_needle]])` now takes `branch_needle`
and `remote_needle` as optional arguments and matches just the branches whose
name contains `branch_needle` and remote contains `remote_needle`.
git fetch: accept several remotes The "--remote" option can be repeated, and the "git.fetch" key is now a list.
2023-02-02 21:31:11 +03:00
* `jj git fetch` accepts repeated `--remote` arguments.
config: allow configuration of git remotes for fetch and push operations The `git.fetch` and `git.push` keys can be used in the configuration file for the default to use in `jj git fetch` and `jj git push` operations. By defaut, "origin" is used in both cases.
2023-01-17 16:27:49 +03:00
* Default remotes can be configured for the `jj git fetch` and `jj git push`
operations ("origin" by default) using the `git.fetch` and `git.push`
git fetch: accept several remotes The "--remote" option can be repeated, and the "git.fetch" key is now a list.
2023-02-02 21:31:11 +03:00
configuration entries. `git.fetch` can be a list if multiple remotes must
be fetched from.
config: allow configuration of git remotes for fetch and push operations The `git.fetch` and `git.push` keys can be used in the configuration file for the default to use in `jj git fetch` and `jj git push` operations. By defaut, "origin" is used in both cases.
2023-01-17 16:27:49 +03:00
`jj duplicate`: Allow duplicating several commits at once The `indexmap` crate is used to make `duplicate`'s output have a sane order, making it easier to test. It's also used later to remove duplicate revisions in the `abandon` command.
2023-01-10 09:54:10 +03:00
* `jj duplicate` can now duplicate multiple changes in one go. This preserves
any parent-child relationships between them. For example, the entire tree of
descendants of `abc` can be duplicated with `jj duplicate abc:`.
`jj log`: Change the default of `ui.unique-prefixes` to "styled"
2023-01-22 09:30:10 +03:00
* `jj log` now highlights the shortest unique prefix of every commit and change
config: remove ui.unique-prefixes/log-id-preferred-length in favor of alias
2023-02-14 17:35:40 +03:00
id and shows the rest in gray. To customize the length and style, use the
`format_short_id()` template alias. For details, see
[the documentation](docs/config.md).
`jj log`: option to specify preferred id length The new option is `ui.log-id-preferred-length`. Setting it to 6 is quite convenient for the `jj` repo, for example. Screenshot: https://user-images.githubusercontent.com/4123047/216535699-ad1e2ac8-73dd-44be-b28a-ebdebc00c63c.png
2023-02-06 03:10:25 +03:00
cli: rename `print` to `cat` `jj cat` better matches `hg cat` and, of course, `cat`. I apparently called it `jj print` when I added it in 7a013a59ae98 because I haven't found `hg cat` useful for actually concatenating files. That's still true, and I don't know if we will ever bother to teach `jj cat` to actually concatenate files, but I think the familiarity of `cat` is more important. For reference, Git calls it `git show <rev>:<file>`. I kept `print` as an alias and added a test for it. I also documented the test better. By the way, I've considered adding a command for writing from stdin directly to a specific commit. If we ever do, it might make sense to call that command `write` (e.g. `echo foo | jj write -r @- README.md`). Then it would make sense to add `read` as an alias to `cat`. I'm not sure that's a good idea, but let's leave that for later anyway.
2023-01-18 09:56:09 +03:00
* `jj print` was renamed to `jj cat`. `jj print` remains as an alias.
cmd: when a single remote is defined, default to it for git fetch/push A simple quick implementation of what I've suggested on discord
2023-04-04 16:34:12 +03:00
cli: also sanitize non-colored output printed to a terminal This makes us sanitize ANSI escape bytes in the output if it goes to the terminal, even when it's not colored (by us), such as when using `--color=never`. That means that e.g. `jj cat tests/test_commit_template.rs` will not be colored, but `jj cat tests/test_commit_template.rs | cat` will be. Sanitizing output sent to the terminal might help reduce some security threats based on hiding content by using ANSI escapes. We could add a config option for sanitizing the output, but I'm not sure it'll be useful.
2023-01-22 00:55:34 +03:00
* In content that goes to the terminal, the ANSI escape byte (0x1b) is replaced
by a "␛" character. That prevents them from interfering with the ANSI escapes
jj itself writes.
cli: rename `print` to `cat` `jj cat` better matches `hg cat` and, of course, `cat`. I apparently called it `jj print` when I added it in 7a013a59ae98 because I haven't found `hg cat` useful for actually concatenating files. That's still true, and I don't know if we will ever bother to teach `jj cat` to actually concatenate files, but I think the familiarity of `cat` is more important. For reference, Git calls it `git show <rev>:<file>`. I kept `print` as an alias and added a test for it. I also documented the test better. By the way, I've considered adding a command for writing from stdin directly to a specific commit. If we ever do, it might make sense to call that command `write` (e.g. `echo foo | jj write -r @- README.md`). Then it would make sense to add `read` as an alias to `cat`. I'm not sure that's a good idea, but let's leave that for later anyway.
2023-01-18 09:56:09 +03:00
workspace: add a root subcommand to print the workspace root path
2023-01-24 14:46:59 +03:00
* `jj workspace root` prints the root path of the current workspace.
config: rename [alias] to [aliases], still supporting old name The name of the [alias] section is inconsistent with other table-valued sections ([revset-aliases], [colors], [merge-tools]), so let's rename it. For comparison, `Cargo.toml` also uses plural names (e.g. `[dependencies]`).
2023-01-27 01:26:05 +03:00
* The `[alias]` config section was renamed to `[aliases]`. The old name is
still accepted for backwards compatibility for some time.
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 09:33:24 +03:00
* Commands that draw an ASCII graph (`jj log`, `jj op log`, `jj obslog`) now
cli: rename `ui.graph.format` to `ui.graph.style` I think of it more as style than a format, so using `style` in the config key makes sense to me. I didn't bother making upgrades easy by supporting the old name since this was just released and only a few developers probably have it set.
2023-01-27 21:15:51 +03:00
have different styles available by setting e.g. `ui.graph.style = "curved"`.
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 09:33:24 +03:00
split: allow creation of empty parent or child jj split . => create an empty child jj split nonexistent => create an empty parent
2023-01-29 09:35:41 +03:00
* `jj split` accepts creating empty commits when given a path. `jj split .`
inserts an empty commit between the target commit and its children if any,
and `jj split any-non-existent-path` inserts an empty commit between the
target commit and its parents.
cli: allow to set ui.diff/merge-editor arguments inline For stock merge-tools, having name -> args indirection makes sense. For user-specific settings, it's simpler to set command name and arguments together. It might be a bit odd that "name with whitespace" can be parsed differently depending on the existence of merge-tools."name with whitespace".
2023-02-05 10:41:28 +03:00
* Command arguments to `ui.diff-editor`/`ui.merge-editor` can now be specified
inline without referring to `[merge-tools]` table.
`jj rebase -d` and `jj new`: Allow several commits per argument with `--allow-large-revsets` Eventually, we should be able to rely on `jj op restore` and the `--allow-large-revsets`. argument should likely be removed. This is a temporary measure until we figure out https://github.com/martinvonz/jj/issues/922 and the like. Fixes https://github.com/martinvonz/jj/issues/571
2023-01-31 09:32:18 +03:00
* `jj rebase` now accepts a new `--allow-large-revsets` argument that allows the
revset in the `-d` argument to expand to several revisions. For example,
`jj rebase -s B -d B- -d C` now works even if `B` is a merge commit.
* `jj new` now also accepts a `--allow-large-revsets` argument that behaves
similarly to `jj rebase --allow-large-revsets`.
jj new --insert-before
2023-01-31 22:01:44 +03:00
* `jj new --insert-before` inserts the new commit between the target commit and
its parents.
jj new --insert-after
2023-02-04 23:42:03 +03:00
* `jj new --insert-after` inserts the new commit between the target commit and
its children.
`author`/`committer` templates: add a `username` method I haven't used a proper email address parser as I'm not really sure if it's worth the extra dependency and effort -- thoughts?
2023-02-10 20:01:28 +03:00
* `author`/`committer` templates now support `.username()`, which leaves out the
config: add and parse `ui.log_author_format` for use in the default template Supported values are, - `none` for no author information, - `full` for both the name and email, - `name` for just the name, - `username` for username part of the email, - (default) `email` (or any other gibberish for that matter) for the full email.
2023-02-11 14:07:58 +03:00
domain information of `.email()`.
config: remove ui.log-author-format in favor of template alias
2023-02-15 13:58:18 +03:00
* It is now possible to change the author format of `jj log` with the
`format_short_signature()` template alias. For details, see
[the documentation](docs/config.md).
`author`/`committer` templates: add a `username` method I haven't used a proper email address parser as I'm not really sure if it's worth the extra dependency and effort -- thoughts?
2023-02-10 20:01:28 +03:00
templater: implement symbol/function alias expansion Test vectors are mainly copied from revset.rs and adapted to the template syntax. Closes #1190
2023-02-12 12:41:53 +03:00
* Added support for template aliases. New symbols and functions can be
configured by `template-aliases.<name> = <expression>`. Be aware that
the template syntax isn't documented yet and is likely to change.
feat(diff): add `ui.diff-instructions` option to suppress `JJ-INSTRUCTIONS` file
2023-06-07 05:33:32 +03:00
* The `ui.diff-instructions` config setting can be set to `false` to inhibit the
creation of the `JJ-INSTRUCTIONS` file as part of diff editing.
release: release version 0.6.0 Lots of new features and important bugfixes. Thanks, everyone!
2022-12-05 19:38:47 +03:00
### Fixed bugs
cli: when colocated with Git, export refs on snapshot This fixes the bug described in the previous commit. Because we now print the message about failed exports also while snapshotting, we may end up reporting it twice on one command. I'm not sure it's worth worrying about that. We can deal with that later if it turns out to be a common complaint.
2022-12-09 07:04:33 +03:00
* When sharing the working copy with a Git repo, we used to forget to export
branches to Git when only the working copy had changed. That's now fixed.
cli: append "\n" to commit description specified by -m/--message Otherwise the description set by -m would differ from the one set by editor. This fixes test_describe() which says "make no changes", but previously "\n" would be added by the second "jj describe". As you can see, almost all hashes change in CLI tests. This means in-flight PRs will need to be rebased to update insta snapshots. Description text could be normalized by CommitBuilder, but the caller would have to normalize it beforehand to compare with the current description, so we would need an explicit function anyway. Another idea is to add a newtype that represents a normalized description, and make CommitBuilder require it. Commit::description() will return &Description in place of &str to ensure that commit.description() == raw_str wouldn't compile. Git CLI provides --cleanup=<mode> option to switch normalization rules, but I don't think we'll need such feature.
2022-12-21 07:47:10 +03:00
* Commit description set by `-m`/`--message` is now terminated with a newline
character, just like descriptions set by editor are.
cli: do not search ancestor paths specified by -R/--repository If a workspace path is explicitly specified, it must point to the exact workspace directory. This is the same behavior as 'hg -R'. OTOH, 'git -C' is the option to chdir, so it makes sense to search .git from that directory. This also fixes 'jj -R ../..' which would previously look up '../..', '..', '.', ...
2023-01-10 06:52:06 +03:00
* The `-R`/`--repository` path must be a valid workspace directory. Its
ancestor directories are no longer searched.
revset: ignore valid commit ids unknown to jj
2023-01-13 23:01:50 +03:00
* Fixed a crash when trying to access a commit that's never been imported into
the jj repo from a Git repo. They will now be considered as non-existent if
referenced explicitly instead of crashing.
gitignore: any character can be backslash-escaped You may use "abc\\" in .gitignore to ignore a file named "abc\". In this case, removing training spaces on "abc\\ " must result in "abc\\" as the trailing space is not escaped, the preceeding backslash being part of the previous "\\" escaping sequence.
2023-01-14 20:56:33 +03:00
* Fixed handling of escaped characters in .gitignore (only keep trailing spaces
if escaped properly).
Make `jj undo` work after `jj duplicate` Fixes https://github.com/martinvonz/jj/issues/1050 Thanks to Martin for suggesting the exact fix. The tests go into the new tests/test_duplicate_command.rs, which will be expanded shortly with other tests depending on this bugfix.
2023-01-16 22:22:10 +03:00
* `jj undo` now works after `jj duplicate`.
Git backend: Allow simultaneous rebasing of duplicate commits Fixes https://github.com/martinvonz/jj/issues/27 Fixes https://github.com/martinvonz/jj/issues/694
2023-01-15 10:28:36 +03:00
* `jj duplicate` followed by `jj rebase` of a tree containing both the original
and duplicate commit no longer crashes. The fix should also resolve any remaining
instances of https://github.com/martinvonz/jj/issues/27.
Fix output of `jj debug completion --help` The help strings for fish and zsh were inverted.
2023-01-22 12:24:20 +03:00
* Fix the output of `jj debug completion --help` by reversing fish and zsh text.
git fetch: prune old branch names before adding new ones
2023-02-12 03:43:38 +03:00
* Fixed edge case in `jj git fetch` when a pruned branch is a prefix of another
branch.
release: release version 0.6.0 Lots of new features and important bugfixes. Thanks, everyone!
2022-12-05 19:38:47 +03:00
### Contributors
Thanks to the people who made this release happen!
release: release version 0.7.0 It's been about 10 weeks and 730 commits since 0.6.0, compared to about 7 weeks and 350 commits between 0.5.0 and 0.6.0, so it's time for a new release. There's been significant user-visible changes and code-quality improvements. Thanks, everyone!
2023-02-16 20:26:40 +03:00
* Aleksandr Mikhailov (@AM5800)
* Augie Fackler (@durin42)
* Benjamin Saunders (@Ralith)
* Daniel Ploch (@torquestomp)
* Danny Hooper (@hooper)
* David Barnett (@dbarnett)
* Glen Choo (@chooglen)
* Herby Gillot (@herbygillot)
* Ilya Grigoriev (@ilyagr)
* Luke Granger-Brown (@lukegb)
docs: mention that the "view" object knows about all workspaces I seem to have forgotten to update this when I added support for workspaces a while back. I made some other little touchups while at it.
2022-12-09 02:40:48 +03:00
* Martin von Zweigbergk (@martinvonz)
release: release version 0.7.0 It's been about 10 weeks and 730 commits since 0.6.0, compared to about 7 weeks and 350 commits between 0.5.0 and 0.6.0, so it's time for a new release. There's been significant user-visible changes and code-quality improvements. Thanks, everyone!
2023-02-16 20:26:40 +03:00
* Michael Forster (@MForster)
* Philip Metzger (@PhilipMetzger)
* Ruben Slabbert (@rslabbert)
* Samuel Tardieu (@samueltardieu)
* Tal Pressman (@talpr)
* Vamsi Avula (@avamsi)
* Waleed Khan (@arxanas)
revset: fold nested parents expressions Some other ancestors() expressions can also be substituted. Practically, this is the rule to fold repeated '-' operators to evaluate them lazily.
2022-12-09 16:55:59 +03:00
* Yuya Nishihara (@yuja)
docs: mention that the "view" object knows about all workspaces I seem to have forgotten to update this when I added support for workspaces a while back. I made some other little touchups while at it.
2022-12-09 02:40:48 +03:00
release: release version 0.6.1 The only changes is that we now depend on a released version of `thrift`.
2022-12-06 07:31:59 +03:00
## [0.6.1] - 2022-12-05
No changes, only changed to a released version of the `thrift` crate dependency.
release: release version 0.6.0 Lots of new features and important bugfixes. Thanks, everyone!
2022-12-05 19:38:47 +03:00
## [0.6.0] - 2022-12-05
### Breaking changes
revset: remove redundant candidates argument from filter predicates
2022-10-25 16:08:11 +03:00
* 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 16:20:59 +03:00
`committer(needle)`, `merges()` revsets. Use `x & description(needle)`
instead.
revset: remove redundant candidates argument from filter predicates
2022-10-25 16:08:11 +03:00
revset: give higher precedence to intersection/difference operators Just like hg revsets and major programming languages.
2022-11-16 17:35:12 +03:00
* Adjusted precedence of revset union/intersection/difference operators.
`x | y & z` is now equivalent to `x | (y & z)`.
let branches and remote_branches revset functions take needles as arguments - branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring - remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
2023-01-12 13:01:35 +03:00
cli: drop support for `ui.enable-open-commits` config
2022-11-05 04:24:20 +03:00
* Support for open commits has been dropped. The `ui.enable-open-commits` config
cli: remove `open`/`close` commands
2022-11-05 03:15:35 +03:00
that was added in 0.5.0 is no longer respected. The `jj open/close` commands
have been deleted.
let branches and remote_branches revset functions take needles as arguments - branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring - remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
2023-01-12 13:01:35 +03:00
cli: remove `open`/`close` commands
2022-11-05 03:15:35 +03:00
* `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-30 00:48:13 +03:00
cli: add a command for updating a stale working copy When a workspace's working-copy commit is updated from another workspace, the workspace becomes "stale". That means that the working copy on disk doesn't represent the commit that the repo's view says it should. In this state, we currently automatically it to the desired commit next time the user runs any command in the workspace. That can be undesirable e.g. if the user had a slow build or test run started in the working copy. It can also be surprising that a checkout happens when the user ran a seemingly readonly command like `jj status`. This patch makes most commands instead error out if the working copy is stale, and adds a `jj workspace update-stale` to update it. The user can still run commands with `--no-commit-working-copy` in this state (doing e.g. `jj --no-commit-working-copy rebase -r @ -d @--` is another way of getting into the stale-working-copy state, by the way).
2022-10-02 20:09:46 +03:00
* If a workspace's working-copy commit has been updated from another workspace,
most commands in that workspace will now fail. Use the new
`jj workspace update-stale` command to update the workspace to the new
working-copy commit. (The old behavior was to automatically update the
workspace.)
cli: add git remote rename subcommand
2022-10-19 21:44:39 +03: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 21:07:35 +03:00
* Commands with long output are paginated.
pager: default to `less -FRX` As dbarnett@ reported on #9, our default of `less`, combined with our default of enabling color on TTYs, means that we print ANSI codes to `less` by default. Unless the user has set e.g. `$LESS=R`, `less` is going to escape those codes, resulting in garbage like this: ``` @ ESC[1;35mbb39c26a29feESC[0m ESC[1;33m(no email configured)ESC[0m ESC[1;36m2022-12-03.... ``` I guess most of us didn't notice because we have something like `$LESS=FRX` set. This patch changes our default from `less` to `less -FRX`. Those are the flags we're using for our internal hg distribution at Google, and that has seemed quite uncontroversial. I added a pointer from the changelog to the tracking issue while at it.
2022-12-04 09:03:38 +03:00
[#9](https://github.com/martinvonz/jj/issues/9)
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 21:07:35 +03:00
cli: add git remote rename subcommand
2022-10-19 21:44:39 +03: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 11:23:45 +03: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-21 00:18:34 +03: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 11:11:22 +03: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 07:14:00 +03: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 11:12:37 +03: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 14:41:55 +03: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 13:27:13 +03:00
changelog: fix typo ("specity")
2022-11-08 00:35:34 +03:00
* It is now possible to specify configuration options on the command line
changelog: fix typo ("he" instead of "the")
2022-11-14 20:26:04 +03: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 04:29:26 +03: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 20:44:21 +03: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 21:15:44 +03: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 20:44:21 +03: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 19:39:46 +03: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 21:01:11 +03: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 09:29:06 +03: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 03:13:39 +03:00
* `jj git` subcommands now support credential helpers.
log: warn if the provided path looks like a revset
2022-11-19 02:41:35 +03: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 06:38:25 +03:00
* The new global flag `-v/--verbose` will turn on debug logging to give
let branches and remote_branches revset functions take needles as arguments - branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring - remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
2023-01-12 13:01:35 +03:00
some additional insight into what is happening behind the scenes.
feature: add verbose flag and tracing library
2022-11-20 06:38:25 +03:00
Note: This is not comprehensively supported by all operations yet.
feature: support relative timestamps as a config option
2022-11-26 04:33:24 +03: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-21 02:33:14 +03: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 20:44:21 +03: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)
let branches and remote_branches revset functions take needles as arguments - branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring - remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
2023-01-12 13:01:35 +03: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 20:44:21 +03: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 11:02:15 +03: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 20:44:21 +03:00
[#493](https://github.com/martinvonz/jj/issues/493)
changelog: list fix for #493 was a bugfix, not a feature
2022-12-03 11:02:15 +03: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-03 02:09:07 +03: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-21 02:33:14 +03: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 22:39:28 +03: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-29 02:18:56 +03: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 22:34:38 +03: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 20:49:09 +03: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)
cli: make `jj status` not just care about the first parent It seems like I forgot to update the `jj status` output when I decided (years ago?) that the changes in a commit should always be compared to the auto-merged parents. I was very confused before I realized that `jj status` was showing the diff summary against the first parent. I suppose the fact that `jj status` lists only one parent should have been a hint. Thanks to ilyagr@ for finding this odd behavior. This patch fixes it by making the command list all parents, and changes the diff summary to be against the auto-merged parents.
2022-12-05 07:56:02 +03:00
* When the working-copy commit was a merge, `jj status` would list only the
first parent, and the diff summary would be against that parent. The output
now lists all parents and the diff summary is against the auto-merged parents.
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 10:38:17 +03: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 19:43:13 +03: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 22:34:38 +03:00
* Pranay Sashank (@pranaysashank)
Give the "unset user" warning a trailing newline. At the moment, the unset user warning is lacking a trailing newline, so we end up printing anything else that's output directly on the same line.
2022-12-05 03:30:32 +03:00
* Luke Granger-Brown (@lukegb)
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 10:38:17 +03:00
release: release version 0.5.1 This point of this release is just to trigger the release automation on GitHub.
2022-10-18 07:45:04 +03: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 23:41:46 +03: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 22:31:54 +03:00
### Breaking changes
cli: disable open commits by default
2022-08-26 01:18:14 +03: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 22:31:54 +03: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 16:57:13 +03: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 20:44:21 +03: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 18:55:46 +03: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 20:44:21 +03: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 18:55:46 +03: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 16:38:56 +03: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 08:31:18 +03: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 12:14:11 +03: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 20:44:21 +03: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 06:23:01 +03: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 20:44:21 +03: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 06:23:01 +03: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 05:42:15 +03: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 03:36:13 +03: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 06:22:54 +03: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 06:05:08 +03: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 07:14:02 +03: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-19 00:46:12 +03: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 21:00:27 +03: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 21:47:38 +03: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 20:53:50 +03: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 09:53:35 +03: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 20:53:50 +03: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 21:00:27 +03: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 20:44:21 +03: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 23:34:13 +03:00
cli: teach `jj squash` to move only changes to specified paths
2022-04-09 20:27:17 +03: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 19:58:33 +03: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 08:24:35 +03: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 21:35:28 +03: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-07 02:10:50 +03: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 22:58:32 +03: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-07 02:10:50 +03: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 09:54:51 +03: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-10 02:14:42 +03: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 20:04:10 +03: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 08:42:27 +03:00
revsets: allow single internal `-` and `+` characters in symbols (#46)
2022-04-27 19:42:18 +03: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 07:26:21 +03:00
* The new revset function `connected(x)` is the same as `x:x`.
revset: add a `roots()` function
2022-04-13 23:55:47 +03: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 07:30:33 +03: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 08:33:08 +03: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 06:58:41 +03: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 12:52:45 +03: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 06:58:41 +03: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 18:54:47 +03: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 04:45:22 +03: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 22:58:32 +03: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 18:54:35 +03: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 20:38:23 +03: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 10:26:23 +03: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-04 01:25:56 +03: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-05 02:18:03 +03: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 07:16:34 +03: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 08:03:51 +03: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 07:35:56 +03: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 09:25:01 +03:00
### Fixed bugs
merge: fix modify/delete conflict to not resolve
2022-04-06 22:18:24 +03: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 09:25:01 +03: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 09:03:08 +03: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 22:58:32 +03:00
fixed.
working_copy: fix crash when updating and only executable bit changed
2022-04-15 09:03:08 +03: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 06:51:24 +03: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 08:58:16 +03: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 19:20:00 +03: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 20:40:56 +03: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 22:13:43 +03: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-10 01:53:32 +03: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 18:54:35 +03: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 08:15:38 +03: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 07:49:57 +03: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 20:23:46 +03: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 21:09:11 +03:00
* All commands now consistently snapshot the working copy (it was missing from
let branches and remote_branches revset functions take needles as arguments - branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring - remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
2023-01-12 13:01:35 +03:00
e.g. `jj undo` and `jj merge` before).
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 21:09:11 +03:00
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 08:56:59 +03: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 20:17:30 +03: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 20:37:13 +03: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 20:00:13 +03: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-27 00:02:04 +03: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-27 00:53:51 +03: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 20:44:21 +03: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 06:58:04 +03: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 20:44:21 +03:00
[#111](https://github.com/martinvonz/jj/issues/111)
repo: when merging in removed head, rebase descendants (#111)
2022-03-17 06:58:04 +03: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 12:12:08 +03: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 09:03:37 +03: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 16:46:21 +03: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 09:03:37 +03: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 09:01:42 +03: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 07:51:21 +03: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 18:14:01 +03: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 20:44:21 +03: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 18:14:01 +03:00
release: add a changelog
2022-03-12 21:48:51 +03:00
## [0.3.0] - 2022-03-12
Last release before this changelog started.
Reference in New Issue Copy Permalink