jj-git-clone
Clone Git repositories using jj
TLDR
Create a new repo backed by a clone of a Git repo into a new directory (the default directory is the repository name)
Create a clone and use the given name for newly created remote
Clone a Git repo, only fetching the 10 most recent commits
Clone colocating the Jujutsu repo with the Git repo (allowing the use of both jj and git commands in the same directory)
SYNOPSIS
jj git clone [OPTIONS] <REMOTE-URL> [DESTINATION]
Arguments:
<REMOTE-URL>: The URL of the Git repository to clone.
[DESTINATION]: Optional path for the new repository. Defaults to the last component of the URL.
PARAMETERS
--at-op=
Restore the repository to the state at the given operation ID after cloning.
--branch
Specify a particular branch to clone instead of the remote's default branch.
--config-toml
Provide a TOML string to be added to the new repository's config.toml.
--cwd
Change the current working directory before executing the command.
--git-remote
Assign a custom name to the Git remote, instead of the default 'origin'.
--git-args
Pass additional, arbitrary arguments directly to the underlying git clone command.
--help
Display help information for this command or its subcommands.
-r, --revision
Check out a specific revision (change ID or branch name) in the new repository.
-s, --sparse
Initialize the cloned repository with a sparse checkout, only downloading specified files.
--template
Apply a predefined template configuration to the new repository.
-v, --verbose
Enable verbose output to show detailed information during the cloning process.
DESCRIPTION
jj-git-clone is a command from the Jujutsu (jj) version control system, designed to clone a Git repository and initialize it as a new Jujutsu repository. It functions as the git clone equivalent within the Jujutsu ecosystem, allowing users to seamlessly transition from an existing Git project to working with Jujutsu.
When executed, it fetches the Git repository's history and converts it into Jujutsu's internal data model, making all Git commits accessible as Jujutsu changes. This command is crucial for integrating Jujutsu into workflows that involve existing Git repositories, enabling users to leverage Jujutsu's unique features, such as rebase by default, explicit conflicts, and operation logs, while maintaining compatibility with remote Git repositories for pushing and pulling. It handles the initial setup, including configuring the Git remote, simplifying the process of migrating or coexisting with Git.
CAVEATS
- The command internally uses git clone. If git is not installed or not in the system's PATH, jj-git-clone will fail.
- While jj maintains compatibility with Git remotes, some advanced Git features (like submodules) might require specific handling or may not be fully supported directly by jj's data model.
- The cloned repository will be a Jujutsu repository, meaning subsequent operations will use jj commands, not git commands, unless explicitly prefixed (e.g., jj git push).
WORKING WITH GIT REMOTES
After cloning, the Jujutsu repository remains linked to the original Git remote. Users can use jj git fetch to pull updates from the Git remote and jj git push to push local changes back to the Git remote.
JUJUTSU AND GIT COMPATIBILITY
While jj-git-clone creates a Jujutsu repository, the underlying .git directory might still exist (depending on jj's internal implementation details). The key is that jj interacts with Git remotes by converting between jj's internal state and Git's commit graph. This allows co-existence and gradual adoption.
HISTORY
Jujutsu (jj) is a relatively new version control system, developed by Martin Ă…gren, aiming to provide a more intuitive and powerful workflow than Git, while maintaining compatibility with Git repositories. The jj-git-clone command was introduced as a fundamental part of Jujutsu from its early development, recognizing the need for seamless integration with the vast existing ecosystem of Git repositories. Its design reflects Jujutsu's philosophy of building on top of Git's strengths while improving upon its user experience, particularly concerning mutable history and explicit state. It allows jj to act as an alternative frontend to Git.
SEE ALSO
jj(1), jj-init(1), jj-git-push(1), jj-git-fetch(1), git-clone(1)