If you have multiple remotes to push to, you might want to keep some changes
(such as security patches) in your private fork. Git CLI has one upstream remote
per branch, but jj supports multiple tracking remotes, and therefore "jj git
push" can start tracking new remotes automatically.
This patch makes new bookmarks not eligible for push by default. I considered
adding a warning, but it's not always possible to interrupt the push shortly
after a warning is emitted.
--all implies --allow-new because otherwise it's equivalent to --tracked. It's
also easier to write a conflict rule with --all/--deleted/--tracked than with
two of them.
-c/--change doesn't require --allow-new because it is the flag to create new
tracking bookmark.
#1278
I hope we'll have support for copies and renames in not too long. It's
good to have as many versions before that as possible without support
for `jj move`, in case we want to later use that to record a moved
file (maybe as an alias for `jj file move`).
This can be used to find the fork point (best common ancestors) of a
revset with an arbitrary number of commits, which cannot be expressed
currently in the revset language.
The destination commits are selected based on annotation, which I think is
basically the same as "hg absorb" (except for handling of consecutive hunks.)
However, we don't compute a full interleaved delta right now, and the hunks are
merged in the same way as "jj squash". This means absorbed hunks might produce
conflicts if no context lines exist. Still I think this is more intuitive than
selecting destination commits based on patch commutativity.
I've left inline comments to the tests where behavior is different from "hg
absorb", but these aren't exhaustively checked.
Closes#170
Visible aliases interfere with shell completion, at least in Fish. For
example, `jj des<tab>` stops as `jj desc` without adding a space
afterwards, which make me stop for a second and wonder if I need to
add more letters. They also show up in the auto-complete menu.
I added "[aliases: <name>]" as part of the first line of the help text
so the `jj help` output still looks the same.
I originally considered adding deny-list-based implementation, but the Windows
compatibility rules are super confusing and I don't have a machine to find out
possible aliases. This patch instead adds directory equivalence tests.
In order to test file entity equivalence, we first need to create a file or
directory of the requested name. It's harmless to create an empty .jj or .git
directory, but materializing .git file or symlink can temporarily set up RCE
situation. That's why new empty file is created to test the path validity. We
might want to add some optimization for safe names (e.g. ASCII, not contain
"git" or "jj", not contain "~", etc.)
That being said, I'm not pretty sure if .git/.jj in sub directory must be
checked. It's not safe to cd into the directory and run "jj", but the same
thing can be said to other tools such as "cargo". Perhaps, our minimum
requirement is to protect our metadata (= the root .jj and .git) directories.
Despite the crate name (and internal use of std::fs::File),
same_file::is_same_file() can test equivalence of directories. This is
documented and tested, so I've removed my custom implementation, which was
slightly simpler but lacks Windows support.
It would be nice to not need to go the documentation website. This aims
to solve that by introducing the concept of keyword to the help
command.
Basically, keywords are things that we want to add help messages to,
but they don't necessarily have an associated subcommand.
For now we only have two keywords:
- `revsets`: Shows the docs for revsets
- `tutorial`: Shows the tutorial that is on the documentation
You get the keyword content by tipping `jj help --keyword revsets` or
`jj help -k revsets`.
You can also list the available keywords with `jj help --help`.
It would be nice to have all the documentation on the keywords, maybe
a next commit could do it.
We had documented that we support `git.auto-local-bookmark` but we
don't. The documentation has been incorrect since d9c68e08b1. This
patch fixes it by adding support for `git.auto-local-bookmark` with
fallback to the old/current `git.auto-local-branch`.
.
Allow unsetting config values similar to `git config unset`.
```bash
$ jj config set --user some-key some-val
$ jj config get some-key
some-val
$ jj config unset --user some-key
$ jj config get some-key
Config error: configuration property "some-key" not found
For help, see https://martinvonz.github.io/jj/latest/config/.
```
Unsetting a key, which is part of a table, might leave that table empty.
For now we do not delete such empty tables, as there may be cases where
an empty table is semantically meaningful
(https://github.com/martinvonz/jj/issues/4458#issuecomment-2407109269).
For example:
```toml
[table]
key = "value"
[another-table]
key = "value"
```
Running `jj config unset --user table.key` will leave us with `table`
being empty:
```toml
[table]
[another-table]
key = "value"
```
For a new user, it is not clear how to view the full commit
message/description of a change with `jj log`.
This fix this, add a new template alias
`builtin_log_compact_full_description` to display the commit like
`builtin_log_compact` does but with a full description.
The user can set it to true on the config like this:
```
templates.log = builtin_log_compact_full_description
```
Fixes: #3688
This was added at f5f61f6bfe "revset: resolve 'HEAD@git' just like other
pseudo @git branches." As I said in this patch, there was no practical use case
of the HEAD@git symbol.
Suppose we implement colocated workspaces/worktrees #4436, there may be multiple
Git HEAD revisions. This means HEAD can no longer be abstracted as a symbol of
the "git" remote.
As I said in the preceding patch, I settled on separate pad/truncate functions
instead of a function taking multiple optional parameters. It's less efficient
to process truncation and padding independently, but I don't think that would
matter.
The order of arguments follows the current f(..., content) convention. We can
also add a method syntax, but I'm not sure if it's useful. In order to call a
method of Template type, we'll need to coerce printable object to Template:
concat(author.email()).truncate_end(10).pad_end(10)
^^^^^^
String -> Template
FWIW, String type could provide more efficient truncate/pad methods.
Closes#3183
This allows for more fine-grained control of timestamp formatting, for
example:
```
[template-aliases]
'format_timestamp(timestamp)' = '''
if(timestamp.before("1 week ago"),
timestamp.format("%b %d %Y %H:%M"),
timestamp.ago()
)
'''
```
Closes#3782.
The `coalesce` function takes a list of revsets and returns the commits in the
first revset in the list which evalutes to a non-empty set of commits.
It can be used to display fallbacks if a certain commit cannot be found,
e.g. `coalesce(present(user_configured_trunk), builtin_trunk)`.
Cleans up after 7051effa8f
It's split into "op_log operation" and just "operation" for the
summaries (as suggested by Yuya). The color labels use "operation".
A new module is added to jj_lib which exposes a function
get_annotation_for_file. This annotates the given file line by line with
commit information according to the commit that made the most recent
change to the line.
Similarly, a new command is added to the CLI called `jj file annotate` which
accepts a file path. It then prints out line by line the commit
information for the line and the line itself. Specific commit
information can be configured via the templates.annotate_commit_summary
config variable
The change was originally made during the last release cycle, so the hunks were
based and rebased on top of the previous release section.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Templates can be formatted (using labels) and are usually sanitized
(unless for plain text output).
`raw_escape_sequence(content)` bypasses both.
```toml
'hyperlink(url, text)' = '''
raw_escape_sequence("\e]8;;" ++ url ++ "\e\\") ++
text ++
raw_escape_sequence("\e]8;;\e\\")
'''
```
In this example, `raw_escape_sequence` not only outputs the intended
escape codes, it also strips away any escape codes that might otherwise
be part of the `url` (from any labels attached to the `url` content).
Not all formatters (namely FormatRecorder) are supported yet.
Change-Id: Id00000004492dbf39e50f3b7090706839d1d8d45
One particular use case for these is escape sequences -- and to that
end, I'm also adding `\e` as a shorthand for `\x1b`.
Change-Id: Id000000040ea6fd8e2d720219931485960c570dd
move already supports these, so this improves squash's parity (I believe
squash is strictly a superset now) as we inch towards deleting move.
Change-Id: Id00000005f2a7f551cb7a0aa598c6265091a32d1
The default clap's help command doesn't have the ability to accept flags
(e.g --no-pager). The recommended way[1] to solve this is to manually
implement it.
[1]: https://github.com/clap-rs/clap/discussions/5332Fixes: #4501
This patch replaces all call sites with present(trunk()), and adds an explicit
check for unresolvable trunk(). If we add coalesce() expression, maybe it can
be rewritten to coalesce(present(trunk()), builtin_trunk()).
Fixes#4616
The id.shortest() template prints a warning and falls back to repo-global
resolution. This seems better than erroring out. There are a few edge cases
in which the short-prefixes resolution can fail unexpectedly. For example, the
trunk() revision might not exist in operations before "jj git clone".
These flags only apply to line-based diffs. This is easy, and seems still useful
to highlight whitespace changes (that could be ignored by line diffing.)
I've added short options only to "diff"-like commands. It seemed unclear if
they were added to deeply-nested commands such as "op log".
Closes#3781
When `format_short_signature(signature)` is set to `signature.name()` the author names are not yellow like other signature types (eg email and username). When the commit signatures have no colors, they blend in making it hard to distinguish between signatures and commit messages.
If just `name` were set to `yellow`, just like email and username, it affects the colorization of branch names making them also yellow despite them being designated as magenta. Setting `author` and `committer` to `yellow` is specific enough to allow branches to keep their colors while still coloring signature names. This is known to affect signatures in both 'log' and 'show'.
