The pico text editor is effectively absent from the majority of Linux
distributions, having been replaced with nano by virtually all of them.
Some distros have symlinks for `pico` that point to `nano`, but not all
of them. Using nano as the fallback option has a much lower chance of
failure than pico.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
Closes https://github.com/jj-vcs/jj/issues/7189
Colocated repos have some advantages and some disadvantages. On the
whole, I think making Git repos colocated by default is a better
trade-off, especially for new users. With the `git.colocate` setting,
(experienced) users can easily change this according to preference.
A non-exhaustive list of pros and cons of colocated repos:
pros:
* Many code editors show the changes one is currently working on based
on Git's "dirty worktree".
* There are a lot of tools that integrate with Git which don't work at
all in non-colocated repositories.
* There are a lot of Git features that Jujutsu doesn't have yet. When
users ask for them, the answer is usually: "Just colocate your repo
and run git directly for now." It's a strength that Jujutsu can focus
on what makes it special and not have to rush the reimplementation of
every niche feature of Git. Examples: `git rebase` tracking file
renames, `git bisect`, `git tag`, `git range-diff`, submodules.
cons:
* Jujutsu performs worse in colocated repositories with lots of refs,
because of the automatic `jj git import`.
* Colocated repos make branch@git references show up in Jujutsu output,
which is usually just aesthetically displeasing or possibly even
confusing to inexperienced users.
* Interleaving jj and (mutating) git commands can lead to confusing
situations. Examples:
* Creating a commit with git instead of jj will often leave a
duplicate "work in progress" commit in Jujutsu's log.
* Some IDEs periodically run `git fetch` in the background. This can
lead to conflicted branches and divergent change IDs, something many
people struggle with.
Tombi is an LSP that complains about the "$schema" key, because it
itself is not actually part of our schema. Taplo is another LSP that
can read this comment directive. Using a comment seems generally more
appropriate. Syntax highlighting makes comments usually less visible,
indicating that the directive is not actually part of the configuration
data.
This patch doesn't add builtin_evolog_redacted template because I'm not sure if
we want to collect evolution log for debugging purpose. The redacted template
can be added later if needed.
Most users colocate all of their repositories or none of them. A config
option is more convenient in that situation.
There are also plans to make colocated repos the default. This change
paves the way to flip the default easily.
Closes#2507.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
On Windows, spawning a child process finds the command relative to the
parent's working directory. If a command is specified as
`["path/inside/repo/tool.exe"]`, then tool won't be found if `jj fix` is
run from a subdirectory of the workspace.
There doesn't seem to be a good way to change this behavior, nor does it
seem easy to convert `program` into an absolute path because
`["tool.exe"]` could refer either to a file on the PATH or a file
committed at the root of the repository.
So, we add a new variable `$root` that can be used in this situation.
Workspace-relative tools on Windows should be defined using this
variable:
```toml
# Tools on the PATH
command = ["tool.exe"]
# Workspace-relative tools
command = ["$root/tool.exe"]
command = ["$root/nested/dir/tool.exe"]
```
On Unix, the command is found relative to the working directory of the
child process, so this isn't an issue.
Fixes#7144
Not setting `diff-args` is equivalent to `diff-args=["$left",
"$right"]`, which I also documented here.
I couldn't decide whether the new error should be part of
`DiffRenderError`, `DiffGenerateError`, or `MergeToolError`. Since the
treatment of diff formatters is already very different from other merge
tools, I just made it a CommandError for now.
Since divergent/conflicted symbols no longer resolve to multiple revisions, it's
less scary to allow "large" revsets than before.
The config doc is removed because it's largely duplicated from the revsets doc,
and the config key will be removed.
#6016
It isn't necessary to include shebangs in scripts passed into
`util exec` since you're already explicitly calling out the shell you'd
like to use. This change removes shebangs from examples for `util exec`
and adds a note below calling this out.
This allows users to override the external tool set in ~/.jjconfig.toml. The
config variable is renamed to ui.diff-formatter to be consistent with the other
diff/merge editor settings.
--tool=:<format> support will be added separately.
Closes#3327
Since jj operates in detached HEAD state, a tracking bookmark isn't technically
needed in order to check out a commit. I usually employ this and delete
unmanaged local bookmarks after cloning repository. This option will automate
the setup.
I spent quite a while confused by the presence of
`if(!trailers.contains_key("Change-Id")` in the `commit_trailers` example. My
thinking was: if `commit_trailers` already performs deduplication, then isn't
this logic useless?
Eventually I realized that the `commit_trailers` deduplication works on the
entire line, not just the key as I'd assumed. (And that makes sense for
trailers like Signed-off-by that can appear more than once.)
I've reworded the `commit_trailers` documentation to try to make this more
clear.
This makes it easier to override just the default description without
having copy the whole default template (and having to keep it up to
date with new versions).
namely Signed-off-by and Change-Id
`format_signed_off_by_trailer` will be formatted properly if the author
name is not set, but will contain the email placeholder if the author
email is not set, as I haven't found a way to make the template
generation fail.
`format_gerrit_change_id_trailer` is based on jj's change id, but it
needed to be padded to reach 40 characters. Zero-padding is kind of
boring so I've used `6a6a6964`, the hexadecimal representation of `jjid`
in ascii.
Because the trailer value runs up to the end of the line, they are
all terminated with a new line. This way it's also convenient to
define these trailers in the `commit_trailers` template:
[templates]
commit_trailers = '''
format_signed_off_by_trailer(self)
++ format_gerrit_change_id_trailer(self)
'''
This allows the customization of the duplicated commit descriptions.
An ideal use case for this is emulating `git cherry-pick -x`, as
illustrated in the tests.
Add a new `template.commit_trailer` configuration option. This template
is used to add some trailers to the commit description.
A new trailer paragraph is created if no trailer paragraph is found in
the commit description.
The trailer is not added to the trailer paragraph when the trailer is
already present, or if the commit description is empty.
The original idea was to flatten left/right conflict trees and pair up adjacent
negative/positive terms. For example, diff(A, B-C+D) could be rendered as
diff(A, B) and diff(C, D). The problem of this formalization is that one of the
diff pairs is often empty (because e.g. A=B), so the context is fully omitted.
The resulting diff(C, D) doesn't provide any notion why the hunk is conflicted,
and how it is different from A.
Instead, this patch implements diffs in which each left/right pair is compared.
In the example above, the left terms are padded, and the diffs are rendered as
diff(A, B), diff(-A, -C), diff(A, D). This appears to be working reasonably well
so long as either side is resolved or both sides have the same numbers of terms.
Closes#4062
This helps detect whether the last line is "JJ:" instruction or not. It seems
also nice that I don't have to insert newline to reflow the edited paragraph.
