As we have discussed many times on Discord and GitHub, `--destination`
is not a great name because `--insert-before` and `--insert-after` are
also destinations. The most popular alternative seems to be
`--onto`. We already use that term in descriptions in several places,
such as in the help text for `rebase -d` where we say "The revision(s)
to rebase onto". This patch therefore renames the `--destination` flag
to `--onto`.
The short name naturally becomes `-o`. That is perhaps a little
unfortunate because it's a common short name for `--output <file>`
arguments, but we don't use that anywhere so it seems fine.
Perhaps we should also rename `--source` (used by `rebase` and `fix`)
to something else. Perhaps the most obvious name is `--descendants`,
but the short form would be `-d`, which is of course already taken by
`--destination` in the case of `rebase`. Either way, I'm leaving that
rename for later. It would be good to do it before next release if we
are going to do it, though.
Closes#7941
This enables configuration to be conditionally applied based on the
hostname set in `operation.hostname`. Users can now use
`--when.hostnames = ["host-a", "host-b"]` in their config files to apply
settings only on specific machines.
Fixes: #6441
Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
A typical use case is to query bookmarked revisions ignoring auto-generated
bookmarks. `bookmarks() ~ bookmarks(x)` doesn't work because a revision may have
multiple bookmarks. It's also nice that we can document the default of
`remote_bookmarks()` as `remote_bookmarks(remote=~exact:"git")`.
Closes#7665
When I first read this document I was confused by two things:
- This looks like a list of people whose contributions are owned by
their employer (for copyright purposes). If so why are there only a
few companies in the list?
- If not that, what is it for?
I found the answers by reading more carefully, and by checking the
original commit message. This is an attempt to make these answers
immediately obvious.
This new command lets you turn a non colocated git repo into a colocated repo or vice-versa (by using the `jj git colocation enable` and `jj git colocation disable` commands respectively).
These commands simply implement the instructions found in https://github.com/jj-vcs/jj/blob/main/docs/git-compatibility.md#converting-a-repo-into-a-co-located-repo
You can also call `jj git colocation status` to show the current colocation status and `jj colocation` to show a help message (with the list of sub-commands).
We currently say "you can disable colocation which does X". If found
it unclear whether "X" describes what colocation does or what
disabling it does. I think can simply describe what colocation does
here. The next paragraph explains how to disable it.
Since we can now update tags internally, local and remote tags may be out of
sync in non-colocated Git repositories. "tags" template should indicate that.
This is a stripped-down version of cmd_bookmark_set(). Since tags shouldn't
usually be rewritten, I've made it fail on updating existing tags by default.
Functionality remains the same; this only affects the docs. This change
points users to supported formats for the `Timestamp.after()` and
`Timestamp.before()` methods, which can already be found in the revset
"Date pattern" type.
- Added support for workspace-specific configuration using `jj config` commands.
- Introduced `--workspace` option to `jj config edit`, `jj config set`, and `jj config unset`.
- Workspace configuration file is stored in `.jj/workspace-config.toml` per workspace.
- Simplified workspace path handling logic.
- Updated documentation and test snapshots to reflect new behavior.
This improves flexibility for users working across multiple workspaces.
Co-authored-by: Eidolon <furyhunter600@gmail.com>
Co-authored-by: ase <adam@sandbergericsson.se>
Remote names are potentially sensitive? Unsure, so better to redact them.
For getting the "*": This could have been done without modifying the
Rust side, with e.g. `stringify(bookmark).ends_with("*")`. However, this
feels brittle.
With adding `.synced()` to the template language, bookmark formatting
_could_ be done entirely in templates now. I don't know if that's
desired, so leaving for a potential future commmit.
This follows Git's merge driver interface which makes this information
available using the `%P` variable. It is useful for merge drivers to
adapt their behaviour based on the type of file supplied.
Our own tutorial and the one by Steve Klabnik both require experience
with Git. Adding a link to "Jujutsu for everyone" will give newcomers
without that experience an appropriate starting point for learning
Jujutsu.
Provide a bit more detail about the JJ to Gerrit change mapping, advice
on handling splits and squashes, as well as the existing FAQ
configuration for adding Change-Id directly to change descriptions.
