Add support for jujutsu VCS

[lopukhov]

Problem

jujutsu is a new git-compatible DVCS with a mix of features from different previous VCS and has become my main VCS for personal projects. Right now cargo does not support the creation of a new project with jj as its VCS and I would like to add it to the list of VCS that can be chosen when creating a new project.

Proposed Solution

The solution is fairly simple as it only has to follow how other VCS are being supported.

I have already implemented it following the implementation of the support for pijul and was going to create a PR but then I noticed that I had to create first an issue and for it to be accepted. If the issue is accepted I will create the PR with the code I have written.

Notes

No response

[weihanglo]

I was not here when Cargo was integrating pijul, so don't feel bad if I ask you more question than pijul integration. Here are some thoughts.

• How widely used is jujutsu as of now?
• Cargo's VCS integration is mostly around project initialization and ignore files. How's the ignore support in jujutsu?
• The story of cargo fix support is incomplete. You may also look into it to add some level of supports.
• If cargo template https://github.com/rust-lang/cargo/issues/5151 comes true someday, is it possible Cargo just let people customize hooks for VCS, so it doesn't need to contain VCS logic in the codebase?

[lopukhov]

Thank you for your response. Dont worry :smile: I understand that the integration of pijul was a long time ago and things may be different, to answer based on the best of my knowledge:

• I would guess not very much. From a presentation the author of jj gave last year it looks like Google may start using it internally, but I am not sure that a lot of people are using it at the moment.
• Because it is git-compatible it uses a .gitignore file
• I am not sure I understand what do you mean, could you please elaborate?
• I did not realize that was a feature that was being worked on, it looks like what you are saying is true, VCS support can be implemented through templates instead of hardcoding it in the codebase.

[epage]

For reference, #3842

[ehuss]

The team discussed this a bit today, and here are some thoughts we had about adding new VCS support:

• At this time, we probably would not accept adding another VCS to cargo new support as-is. Although it is a relatively small amount of code, Cargo has a near indefinite stability requirement that makes it difficult to remove options if they are causing problems or are no longer supported. These also aren't tested for proper support (for example fossil was broken for some time before it was fixed), and I think it is unlikely we would want to install and support these in our CI infrastructure.
• It isn't clear what it means to "support" a VCS, as Cargo has many areas where it interacts with version control systems, such as:
  • cargo new, initializing repos and setting up ignore files
  • Dirty checks for cargo publish or cargo fix.
  • File listings for cargo publish or fingerprinting (particularly with build scripts).
  • The .cargo_vcs_info.json file for publishing.
  • Dependencies (git only for now).

• We are interested in making it extensible so that people can independently add support for other VCS systems, particularly for the cargo new case (perhaps some tiered level of support).

  One idea floated out is to have some kind of data file that describes the commands cargo should run to perform certain actions (such as initializing a repo, adding ignore entries, etc.). There are some concerns about how well that might work, such as whether or not sufficient support could be included in a declarative way, or whether or not users would actually bother trying to configure something like that, since the integration might be awkward.

  Unfortunately this isn't something anyone one the team is able to prioritize at this time, so we may not be able to help with moving that feature along. However, if other people want to discuss such ideas (on this issue or the internals forum), that can help try to shape what might be needed to make Cargo extensible (if it is even feasible). Eventually such an effort would need to go through an RFC to get accepted.

• There also might be interactions with Cargo templates that we're uncertain about. They may be independent features, but it is something to consider.