I'm going to fix misuse of CommandHelper::for_loaded_repo(), which expects
that the given repo respects the --at-operation option.
I don't think all of the added tests are useful, but "clone
--ignore-working-copy" might be legit as a replacement for bare repos.
The user can define the setting `git.private-commits` as they desire. For
example:
git.private-commits = 'description(glob:"wip:*")'
If any commits are in this revset, then the push is aborted.
If a commit would be private but already exists on the remote, then it does
not block pushes, nor do its descendents block pushes unless they are also
contained in `git.private-commits`.
Closes#3376
The user probably would expect the path to be relative to their current
directory rather than the workspace root. For instance, if the user is
in a child directory and runs `jj workspace add ../../name`, then they
might be surprised if we printed "../name" instead of "../../name".
These functions mirror the ones in WorkspaceCommandHelper. I'm not sure if all
of them will have to be public, but parse_commit_template() might be useful in
order to implement description template.
Prevents a warning from being printed when renaming branches in a
colocated repo, since git tracking branches were being considered as
remote tracking branches.
It's inconvenient that we have to quote glob patterns as 'glob:"*.rs"'. Suppose
filesets are usually specified in shell, it's better to allow unquoted strings
if possible. This change also means we'll probably abandon #2101 "make the
parsing of string arguments stricter."
Note that we can no longer introduce ? operator or [] subscript syntax in
filesets.
Closes#4053
Now that `jj move` does not accept `-r` (since it has `--from` and `--to`), `jj set --to` seems more useful
than `jj set -r`. `create --to` is also added for ease of switching
between `branch create` and `branch move`.
This patch adds TreeDiff template type to host formatting options. The main
reason of this API design is that diff formats have various incompatible
parameters, so a single .diff(files, format[, options..]) method would become
messy pretty quickly. Another reason is that we can probably add custom
summary templating support as diff.files().map(|file| file.path()..).
RepoPathUiConverter is passed to templater explicitly because the one stored
in RevsetParseContext is behind Option<_>.
This will help remove lifetimed &dyn Repo from diff object in templater.
Function arguments are reordered in a way that all show_*() functions have
common parameters in the same order.
Since fileset and revset languages are syntactically close, we can reparse
revset expression as a fileset. This might sound a bit scary, but helps
eliminate nested quoting like file("~glob:'*.rs'"). One oddity exists in alias
substitution, though. Another possible problem is that we'll need to add fake
operator parsing rules if we introduce incompatibility in fileset, or want to
embed revset expressions in a fileset.
Since "file(x, y)" is equivalent to "file(x|y)", the former will be deprecated.
I'll probably add a mechanism to collect warnings during parsing.
Currently, when there is a commit with two predecessors, the graph
splits into two branches, and all of the predecessors on the first
branch are printed before all of the predecessors on the second branch.
This causes the graph to grow wider with each squashed commit, since the
second branch must always get indented one level farther each time a
commit is squashed. I have some commits where the graph is indented more
than 10 levels due to squashing more than 10 times, making it very
difficult to read.
Reversing the order and printing the second branch before the first
branch prevents this unnecessary indentation and makes the graph easier
to read. This does not change the order of the edges in the graph (i.e.
the first predecessor is still the first edge and the second predecessor
is still the second edge in the graph).
I used to use "remote_branches() & ~mine()" to exclude "their" branches from
the default log, and I don't think that's uncommon requirement. Suppose
untracked branches are usually read-only, it's probably okay to make them
immutable by default.
This helps migrate internal [u8] variables to BStr.
b"" literals in tests are changed to &str to get around potential type
incompatibility between &[u8; N].
Adds support for revset functions `tracked_remote_branches()` and
`untracked_remote_branches()`. I think this would be especially useful
for configuring `immutable_heads()` because rewriting untracked remote
branches usually wouldn't be desirable (since it wouldn't update the
remote branch). It also makes it easy to hide branches that you don't
care about from the log, since you could hide untracked branches and
then only track branches that you care about.
This not only makes the output easier to read, but also protects against
implementation detail changes in `write!` when used with a format
string (especially, how many times and with what strings it calls the
underlying writer).
Partially resolve a 1.5‐year‐old TODO comment.
Add opt‐in syntax for case‐insensitive matching, suffixing the
pattern kind with `-i`. Not every context supports case‐insensitive
patterns (e.g. Git branch fetch settings). It may make sense to make
this the default in at least some contexts (e.g. the commit signature
and description revsets), but it would require some thought to avoid
more confusing context‐sensitivity.
Make `mine()` match case‐insensitively unconditionally, since email
addresses are conventionally case‐insensitive and it doesn’t take
a pattern anyway.
This currently only handles ASCII case folding, due to the complexities
of case‐insensitive Unicode comparison and the `glob` crate’s lack
of support for it. This is unlikely to matter for email addresses,
which very rarely contain non‐ASCII characters, but is unfortunate
for names and descriptions. However, the current matching behaviour is
already seriously deficient for non‐ASCII text due to the lack of any
normalization, so this hopefully shouldn’t be a blocker to adding the
interface. An expository comment has been left in the code for anyone
who wants to try and address this (perhaps a future version of myself).
`tx.format_commit_summary()` can be expensive because it needs to build
an IdPrefixContext now, so it's best to avoid formatting instruction
messages unless they are actually required.
Patience diff starts by lining up unique elements (e.g. lines) to find
matching segments of the inputs. After that, it refines the
non-matching segments by repeating the process. Histogram expands on
that by not just considering unique elements but by continuing with
elements of count 2, then 3, etc.
Before this commit, when diffing "a b a b b" against "a b a b a b", we
would match the two "a"s in the first input against the first two "a"s
in the second input. After this patch, we ignore the "a"s because
their counts differ, so we try to align the "b"s instead.
I have had this commit lying around since I wrote the histogram diff
implementation in 1e657c5331. I vaguely remember thinking that the
way I had implemented it (without this commit) was a bit weird, but I
wasn't sure if this commit would be an improvement or not. The bug
report from @chooglen today of a case where we behave differently from
Git is enough to make me think that we make this change after all.
#761
I've run into change ID prefixes being 4-5 characters instead of the
usual 1-2 characters in commands like `jj duplicate` and `jj split`
fairly often, and it seems like this should resolve that.
For the same reason as the previous commit.
Created and moved stats are printed separately because it's unusual to do both
within one "branch set" invocation.
For the same reason as cdc0cc3601. This will help notice problems like wrong
target revision.
The warning for multiple branches is reorganized as a hint for "-r" option,
which I think is the main purpose of this warning. Unlike "squash", we don't
check if an argument can be parsed as a revset because branch name is usually
a valid symbol expression.
The output looks somewhat similar to color-words diffs. Unified diffs are
verbose, but are easier to follow if adjacent lines are added/removed + modified
for example.
Word-level diffing is forcibly enabled. We can also add a config knob (or
!color condition) to turn it off to save CPU time.
I originally considered disabling highlights in block insertion/deletion, but
that wasn't always great. This can be addressed separately as it also applies
to color-words diffs. #3958
Forgetting a workspace removes its working-copy commit, so it makes
sense for it to be abandoned if it is discardable just like editing a
new commit will cause the old commit to be abandoned if it is
discardable.
It's nice to see the result of "branch move", "create", etc., and this is more
important in "branch move" because the source branches can be specified in an
abstracted way. I originally considered printing a list of affected branches,
but it looked rather verbose. Since the destination revision is unique, we can
use commit_summary template instead.
This patch also removes a warning about multiple branches because the branch
names are included in the commit summary. I think the hint message is good
enough to signal possible mistake.
We usually print stats at the end of mutable operation, and I think these
messages are useful even if N = 1. I understand that "Deleted N" (N > 1) is
unusual and the original intent of these messages was to signal possible
mistakes. However, I don't think printing N=1 stats would nullify the original
purpose.
No emptiness check is needed for delete/forget, but names can be empty in
track/untrack because of noop changes.
The last hunk could be truncated instead, but the .peekable() version is easier
to follow. If we truncated lines, we would have to adjust line ranges
accordingly.
show_context_after was set once when DiffHunk::Different received, and was
never turned off. This means DiffHunk::Matching is not supposed to repeat.
Under this condition, we can assume that removed/added lines exist if lines
isn't empty.
At work, a user encountered a panic upon attempting to create a dir at
the line in the diff below, but it turned out to be difficult to debug
because I didn't know what the path was. There already is a mechanism to
add path context in the lib crate; make it available in the cli crate as
well, and use the mechanism to add path context to "workspace add".
It's common to create empty working-copy commits while using jj, and
currently the author timestamp for a commit is only set when it is first
created. If you create an empty commit, then don't work on a repo for a
few days, and then start working on a new feature without abandoning the
working-copy commit, the author timestamp will remain as the time the
commit was created rather than being updated to the time that work began
or finished.
This commit changes the behavior so that discardable commits (empty
commits with no description) by the current user have their author
timestamps reset when they are rewritten, meaning that the author
timestamp will become finalized whenever a commit is given a description
or becomes non-empty.
Now, the command for `jj git remote add` is `cmd_git_remote_add` and its
argument type is `GitRemoteAddArgs`. This should make it easier to find
the CLI docs and the implementation for commands.
This is how `jj branch` commands were already set up in this way. The
`jj op` commands were also already set up in this way, except the
functions are called e.g. `cmd_op_undo`, I kept this for simplicity.
I was mainly motivated by the `jj file` commands. Most other commands
had functions already named in the above pattern, but used to have
shorter argument type names.
We have two other kinds of working copies at Google and it's sometimes
useful to get the basic information about operation id and tree id for
them, for exampel for debugging stale workspaces. This patch adds a
command for that.
We could instead have made the old `jj debug working-copy` command
work for all kinds of working copies (like the new command) and only
have extra information for the standard local-disk implementation. I
don't feel strongly either way and could do it other other way instead
if people prefer that.
While explaining branch tracking behavior, I find it's bad UX that a deleted
branch can be re-"create"d with tracking state preserved. It's rather a "set"
operation. Since deleted tracking branch is still listed, I think it's better
to assume that the local branch name is reserved.
https://github.com/martinvonz/jj/discussions/3871
Renaming to deleted tracking branch is still allowed (with warning) because the
"rename" command can't handle tracked remotes very well. If it were banned, bad
rename couldn't be reverted by using "jj branch rename". It would be confusing
if "rename a b" succeeded with warning, but the following "rename b a" failed.
This will help inline view.remove_branch() in cmd_branch_forget(). I don't
care much about owned (String, _) vs (&str, _), but we can't simplify the
lifetime issue in find_forgettable_branches() anyway. So I made all callers
pass cloned Arc<ReadonlyRepo> and borrow (name, target) pairs from there.
It was convenient that expression nodes can be compared in tests, but no
equivalence property is needed at runtime. Let's remove Eq/PartialEq to
simplify the extension support.
We now have two `cmd_show` in the repo. I think this one should become
`cmd_file_show`, but this should be done uniformly over all the commands
for consistency.
I did *not* keep `print` as an alias (I couldn't find a compelling
reason to do it), but let me know if anyone feels like keeping it.
We don't want e.g. `jj diff --git` to have underlined text because
it's redundant there. This patch fixes that by adding a new `token`
label used only in the color-words diff (for now - it may be used in
git diffs in the future).
This means we could remove the `line_number` label but I left it
because there's little harm in having it and it seems like it can
still be useful.
Thanks to @yuja for noticing and suggesting the fix.
If you want to set a background color on added/removed lines, you
currently get the same style on the line numbers. This patch lets you
specify a different style by overriding it on the line numbers.
Since "set <thing>" often adds a <thing> if not exists, it make some sense
that "branch set" does upsert. The current "branch set" use case is now covered
by "branch move", so it's okay to change the "set" behavior.
If new branch is created by "branch set", status message and hint will be
printed to help migration. The user should be able to undo creation if it was
a mistake.
Closes#3584
There are several bugs in both the tests and in the implementation
that are made more clear by showing the log output before and after
running the command.
This allows users to jump to the next conflict in the ancestors or children of
the start commit.
Continues work on #2126
Co-Authored-By: Noah Mayr <dev@noahmayr.com>
This allows users to easily filter a commit range by conflicts, which will be needed for `next/prev`
further down in the next commit. Users which benefit from it were also migrated.
In a repo of mine I wanted to do something like the following to push all of my
leaves to the remote as backup:
jj git push -c 'all:heads(base::) & mine() ~ empty()'
But couldn't, because `jj git push` doesn't handle large revsets, even though
it does handle multiple `-c` arguments, so I had to work out some pipe-to-xargs
command instead.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The follow up diff will make `-c` accept large revsets, so it won't make any
sense to print out the original expression when multiple branches will be
created from it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is another big subcommand module. Let's split it up.
I'm not a big fan of r#move syntax, but we already have one in src/commands,
so there's no point to avoid it.
The error message that says something like 'Workspace "default"
doesn't have a working copy' confused me when I saw it. The problem
it's describing is that the repo view doesn't have a working-copy
commit for the given workspace id. Saying "working-copy commit"
instead of "working copy" hopefully clarifies it a bit.
This basically supersedes the current "branch set" command. The plan is to turn
"branch set" into an "upsert" command, and deprecate "branch create". (#3584)
Maybe we can also add "branch set --new" flag to only allow creation of new
branches. One reason behind this proposed change is that "set" usually allows
both "creation" and "update". However, we also need a typo-safe version of
"set" to not create new branches by accident.
"jj branch move" is useful when advancing ancestor branches. Let's say you've
added a couple of commits on top of an existing PR branch, you can advance the
branch by "jj branch move --from 'heads(::@- & branches())' --to @-". If this
pattern is super common, maybe we can add --advance flag for short.
One drawback of this change is that "git branch --move" is equivalent to
"jj branch rename". I personally don't find this is confusing, but it's true
that "move" sometimes means "rename".
This basically backs out 8706fadca1 "cli: inline check for
non-fast-forwardable branch move." I'm going to add another subcommand that
moves existing branches.
Otherwise they wouldn't be sorted in help. I also reordered the match statement.
Since subcommands are split to per-file modules, there's no point to keep some
logical ordering.
- make an internal set of watchman extensions until the client api gets
updates with triggers
- add a config option to enable using triggers in watchman
Co-authored-by: Waleed Khan <me@waleedkhan.name>
If I can't tell what this comment means, probably nobody else can
either.
I think it might be a copy-paste error from whatever docs I copied the
initial version of the config from.
Still alias function shadows builtin function (of any arity) by name. This
allows to detect argument error as such, but might be a bit inconvenient if
user wants to overload heads() for example. If needed, maybe we can add some
config/revset syntax to import builtin function to alias namespace.
The functions table is keyed by name, not by (name, arity) pair. That's mainly
because std collections require keys to be Borrow, and a pair of borrowed
values is incompatible with owned pair. Another reason is it makes easy to look
up overloads by name.
Alias overloading could also be achieved by adding default parameters, but that
will complicate the implementation a bit more, and can't prevent shadowing of
0-ary immutable_heads().
Closes#2966
I'm going to add arity-based alias overloading, and we'll need function
(name, arity) pair to identify it in alias expansion stack. The exact parameter
names aren't necessary, but they can be embedded in error messages.
Most of the value of `jj fix` over a shell script is in formatting commits
other than `@`. `@::` often doesn't contain those other commits, so `-s @` is a
bad default.
We could get the same effect from `-s 'mutable() & ::@'`, but `reachable()` is
a bit more explicit and simple to read.
We could also base this on excluding `trunk()`, but that just seems like an
indirection for `mutable()` that might ignore the user's intent if they have
configured part of trunk to be mutable.
This addresses issue #3317, where as discussed we want to show the paths to
configuration files if they contain errors, to make it easier for the user to
locate them.
As we discovered in the `jj fix` tests,
`MergedTreeBuilder::write_tree()` doesn't try to resolve conflicts,
not even trivial ones. This patch fixes that.
The goal is to remove special case from parsing functions and provide slightly
better error message. I don't know if we'd want to use "all:" in aliases, but
there are no strong reasons to disable it.
This commit adds an optional flag to be able to push commits with an
empty description to a remote git repo. While the default behavior is
ideal we might need to interact with a repo that has an empty commit
description in it. I ran into this issue a few weeks ago pushing commits
from an open source repo to an empty repo and had to go back to using
git for that push as I would not want to rewrite the history which was
many many years long just for that.
This flag allows users an escape hatch for pushing empty descriptions
for commits and they're sure that they want that behavior.
This commit adds the flag to the `git push` command and updates the docs
for the command. It also updates the original test to make sure that the
flag works as intended to reject the commit when not set and to allow
the commit when the flag is set.
Closes#2633
This simplifies the interface of helper functions. While revset doesn't have
top-level string pattern or integer literal, these parsing helpers could be
used to parse array subscript or n-th parent operator if any.
Previously, it sounded like `jj git` might only include highly-technical
commands, while IMO the most important commands in here are `jj git
fetch` and `jj git push`.
This will allows us to parse "file(..)" arguments as fileset expression by
transforming AST for example. I'm not sure if that's good or bad, but we'll
probably want to embed fileset expressions without quoting.
parse_expression_rule() is split to the first str->ExpressionNode stage and
the second ExpressionNode->RevsetExpression stage. The latter is called
"resolve_*()" in fileset, but we have another "symbol" resolution stage in
revset. So I choose "lower_*()" instead.
Otherwise, newly created default branch would be re-imported as a new Git HEAD.
This could be addressed by cmd_git_init(), but the same situation can be
crafted by using "git checkout -b".
It's copied from test_git_colocated.rs, and switched to commit_id.short()
because full-length commit_id looked too verbose. "all()" history isn't needed,
but it's easier to follow.
Some backends, like the one we have at Google, can restrict access to
certain files. For such files, if they return a regular
`BackendError::ReadObject`, then that will terminate iteration in many
cases (e.g. when diffing or listing files). This patch adds a new
error variant for them to return instead, plus handling of such errors
in diff output and in the working copy.
In order to test the feature, I added a new commit backend that
returns the new `ReadAccessDenied` error when the caller tries to read
certain objects.
I'm going to add a similar message for access denied. That will want
an error message printed at the end. For consistency, let's do the
same for non-file paths.
Clear the rest of the cursor line (from the cursor to the end of the
row) after drawing the progress bar rather than clearing the entire line
before drawing. This reduces flickering on terminal emulators which are
able to redraw rapidly.
I recently needed to test something on top of a two branches at the
same time, so I created a new commit on top of both of them (i.e. a
merge commit). I then ran tests and made some adjustments to the
code. These adjustments belonged in one of the parent branches, so I
used `jj squash --into` to squash it in there. Unfortunately, that
meant that my working copy became a single-parent commit based on one
of the branches only. We already had #2859 for tracking this issue.
This patch changes the behavior so we create a new working-copy commit
with all of the previous parents.
