jj-git-init(1)

💖 NAME

jj-git-init — Create a new Git backed repo. (From the General Commands Manual, bestie — it's giving "short but iconic" 💅)

✨ SYNOPSIS

jj git init [--colocate] [-R|--repository] [--ignore-working-copy]
[--no-colocate] [--no-integrate-operation] [--object-hash] [--git-repo]
[--ignore-immutable] [--at-operation] [--debug] [--color] [--quiet]
[--no-pager] [--config] [--config-file] [-h|--help] [DESTINATION]

🦋 DESCRIPTION

Create a new Git backed repo. That's the whole main-character mission, no cap.

To use an existing Git repository as the backing store, run jj git init from that repository's root directory. This is the usual way to start using Jujutsu in an existing Git checkout. See the colocation docs: https://docs.jj-vcs.dev/latest/git-compatibility/#creating-a-repo-backed-by-an-existing-git-repo.

If the setting git.colocate has the value false, then new repositories will not be colocated. Pass --colocate to override this.

🎀 OPTIONS

• --colocate — Colocate the workspace of the Jujutsu repo with the Git repo. Specifies that the workspace of the jj repo should also be a valid git repo, allowing the use of both jj and git commands in the same directory. The workspace will contain a .git dir in the top-level, so regular Git tools will be able to operate on the repo. This is the default (and this option has no effect) unless the git.colocate config is set to false. The git.colocate config link is: https://docs.jj-vcs.dev/latest/config/#default-colocation. The --colocate option is equivalent to --git-repo=DESTINATION. These options are mutually exclusive.
• --no-colocate — Disable colocation for the workspace of the Jujutsu repo with the Git repo. Prevent Git tools that are unaware of jj and regular Git commands from operating on the repo. The Git repository that stores most of the repo data will be hidden inside a sub-directory of the .jj directory. See the colocation docs for some minor advantages of non-colocated workspaces: https://docs.jj-vcs.dev/latest/git-compatibility/#colocated-jujutsugit-workspaces.
• --object-hash <OBJECT_HASH> — Object hash algorithm for the newly created Git repository. Corresponds to git init's --object-format option. If not given, the git.object-hash config determines the default value. Note that the object hash cannot currently be changed for an existing repo, and not all code forges support SHA-256 repositories yet. See also Git's hash-function-transition document for an in-depth explanation of the migration towards stronger hash functions: https://git-scm.com/docs/hash-function-transition. The git.object-hash config link is: https://docs.jj-vcs.dev/latest/config/#default-object-hash-format. Possible values:
  • sha1
  • sha256
• --git-repo <GIT_REPO> — Specifies a path to an existing git repository to be used as the backing git repo for the newly created jj repo. If the specified --git-repo path is the same as DESTINATION, then a colocated workspace will be created, and both jj and git commands will work on the repo. The git.colocate setting is ignored in this case. If the specified --git-repo path is outside of the given DESTINATION, then the Jujutsa workspace will store a reference to the external Git repository (not a colocated workspace). This option is mutually exclusive with --collate. The colocated workspace link is: https://docs.jj-vcs.dev/latest/git-compatibility/#colocated-jujutsugit-workspaces.
• -h, --help — Print help (see a summary with '-h').
• [DESTINATION] [default: .] — The destination directory where the jj repo will be created. If the directory does not exist, it will be created. If no directory is given, the current directory is used.

🌈 GLOBAL OPTIONS

• -R, --repository <REPOSITORY> — Path to repository to operate on. By default, Jujutsu searches for the closest .jj/ directory in an ancestor of the current working directory.
• --ignore-working-copy — Don't snapshot the working copy, and don't update it. By default, Jujutsu snapshots the working copy at the beginning of every command. The working copy is also updated at the end of the command, if the command modified the working-copy commit (@). If you want to avoid snapshotting the working copy and instead see a possibly stale working-copy commit, you can use --ignore-working-copy. This may be useful e.g. in a command prompt, especially if you have another process that commits the working copy. Loading the repository at a specific operation with --at-operation implies --ignore-working-copy.
• --no-integrate-operation — Run the command as usual but don't integrate any operations. When this option is given, the operations will still be created as usual but they will not be integrated to the operation log. The working copy will also not be updated. The command will print the resulting operation ID. You can pass that to e.g. jj --at-op to inspect the resulting repo state, or you can pass it to jj op restore to restore the repo to that state. You can also pass the ID to jj op integrate to integrate the operation. Note that this does not prevent side effects outside the repo. For example, jj git push --no-integrate-operation will still perform the push.
• --ignore-immutable — Allow rewriting immutable commits. By default, Jujutsu prevents rewriting commits in the configured set of immutable commits. This option disables that check and lets you rewrite any commit but the root commit. This option only affects the check. It does not affect the immutable_heads() revset or the immutable template keyword.
• --at-operation <AT_OPERATION> — Operation to load the repo at. Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, or at the merge of the divergent operations if any. You can use --at-op=<operation ID> to see what the repo looked like at an earlier operation. For example jj --at-op=<operation ID> st will show you what jj st would have shown you when the given operation had just finished. --at-op=@ is pretty much the same as the default except that divergent operations will never be merged. Use jj op log to find the operation ID you want. Any unambiguous prefix of the operation ID is enough. When loading the repo at an earlier operation, the working copy will be ignored, as if --ignore-working-copy had been specified. It is possible to run mutating commands when loading the repo at an earlier operation. Doing that is equivalent to having run concurrent commands starting at the earlier operation. There's rarely a reason to do that, but it is possible.
• --debug — Enable debug logging.
• --color <WHEN> — When to colorize output. Possible values:
  • always
  • never
  • debug
  • auto
• --quiet — Silence non-primary command output. For example, jj file list will still list files, but it won't tell you if the working copy was snapshotted or if descendants were rebased. Warnings and errors will still be printed.
• --no-pager — Disable the pager.
• --config <NAME=VALUE> — Additional configuration options (can be repeated). The name should be specified as TOML dotted keys. The value should be specified as a TOML expression. If string value isn't enclosed by any TOML constructs (such as array notation), quotes can be omitted.
• --config-file <PATH> — Additional configuration files (can be repeated).

---

That's the whole page, bestie 🫶 — footer source/version flex: init and jj-git-init(1), with the date slot doing its little cameo. 💅✨