jujutsu and git-branchless

[pokey]

I see from #654 and #551 (reply in thread) discussion of letting jujutsu take care of some features instead of git-branchless. I didn't realise they could be used side-by-side.

@arxanas do you use both jujutsu and git-branchless in tandem on the same repo? If so, can you talk a bit about which you use for what?

[arxanas]

I do have Jujutsu initialized alongside Git in several of my repos. To be honest, both of the tools are fairly interchangeable for my purposes. Jujutsu has a smartlog (jj log), sensible rebase (jj rebase), undo (jj undo), etc. I like the working copy snapshot feature the most, in which working copy changes are automatically tracked in a commit. Then, it's possible to move changes between commits (including the working copy) with jj move or jj split.

[ppwwyyxx]

Thanks @saolof , I think that captures my feeling as well. When trying jj I feel there is too much to learn for me to be able to use it as smoothly as with git.

For example, jj always snapshoting my current working directory gives me a few confusions.
First I'll need to figure out how to do the equivalent of git checkout older-commit where I bring my current changes to an older commit and amend there (using branchless).
Snapshot also constantly complains about my habbit of putting various program artifacts (sometimes large) in the current directory.
And when running certain commands I need to use HEAD@git instead of HEAD (which I'm used to) because of snapshot.

I'm sure there is a solution to them, but it takes time to learn and adjust habits. I do see a lot of cool things in jj (and I enjoyed fig at google), but I don't have the time to master it to the level of familiarity I have with git. And like @saolof said, when using branchless I'm still using git, but with new helpful commands.

[martinvonz]

FYI, you can pass --colocate to jj git clone to tell it to create a workspace with .git/ and .jj/ as siblings (instead of having .git/ somewhere inside .jj/). That way you can simply use git checkout <commit> <path> as you always have.

(I know the git checkout older-commit thing was just an example, but anyway: the preferred way of doing that with Git these days is git restore --source <commit> <path>, and with jj it's jj restore --from <commit> <path>.)

[arxanas]

@ppwwyyxx you can see my post here, which should answer many questions: #654

Personally, I wish if branchless can keep its simplicity while introducing some nice features of jj (e.g., I wish we have the interactive jj split, and the 1-2 letter shortened commit identifier) , or if jj can have a mode of operation similar to the simple experience of branchless.

I use Jujutsu in the "colocated" mode, which I think helps quite a bit for onboarding onto jj without having to learn all of the jj commands immediately. However, jj even in colocated mode doesn't work for some use-cases currently, such as submodules or Git LFS, but hopefully they will be implemented in the future.

In terms of development, I would rather not spend too much time implementing features for both git-branchless and jj, but I'm optimistic that we can extract many features into libraries that can be used across multiple version control systems, as mentioned in the post above. Since making that post, I've already developed the partial commit TUI that is used in both git-branchless and jj (scm-record).

• We can expect some ideas to migrate from git-branchless to jj, such as git test becoming jj run one day. (It can use the scm-bisect library from git-branchless, if appropriate.)
• And we can expect that some of the ideas won't make it to jj, such as git-branchless's rendering (mangling?) of merge commits in the smartlog 🙂.

On the other hand, it also means that not every feature will be implemented in git-branchless. I haven't implemented e.g. git amend -i since I got it "for free" by integrating the partial commit TUI into jj, which automatically supports interactive amending at that point due to its design. But I am certainly open to PRs implementing those kinds of features, or the ones you listed above (interactive splitting, shortened commit IDs).

@martinvonz Meta's Mercurial had hg githelp, which would accept a Git command and translate it into the corresponding Mercurial command — perhaps we should implement something like that for jj as well.

[ppwwyyxx]

@martinvonz I'm aware of "colocate mode" and I have it on with my branchless repo. It's true that with this mode I can still use git workflows, but still, I had the experience that branchless works better than jj alongside my usual git workflow.

After thinking more, I feel that git restack is probably one of the keys to "incremental adoption from git". To give an example:

I use git checkout older-commit; git commit --amend to edit an old commit or git rebase -i to reorder commits, because I'm used to them. After doing these operations, some commits are rewritten and commits that depend on the old versions will need to depend on the new versions. branchless can git restack to repair my graph of dependencies, similar to hg evolve in fig. This means I don't have to learn new alternatives to the above two git commands: branchless can just work with them.

For jj, however, it appears there isn't a way to "repair" dependencies similar to git restack. (If there is, then it's super non-obvious to me. ) So I'll have to go search and learn how to amend an old commit in jj, and how to reorder history in jj. Hence I feel it's pulling me away from my usual git workflow.

[martinvonz]

First, it's totally fair that git-branchless is a easier to adopt than jj. We should of course do what we can to make it as easy as possible to use jj, but its model is simply slightly different from Git's, so it will always be harder to learn (compared to git-branchless, but hopefully not compared to learning Git from scratch).

For jj, however, it appears there isn't a way to "repair" dependencies similar to git restack. (If there is, then it's super non-obvious to me. ) So I'll have to go search and learn how to amend an old commit in jj, and how to reorder history in jj.

Practically every jj command actually "repairs" your repo. However, it won't know how to repair things you've "broken" by using git. So jj checkout older-commit; jj amend/squash will do what you want. There's an example towards the end of the "Conflicts" section in the tutorial.

[martinvonz]

The tutorial in https://martinvonz.github.io/jj/v0.10.0/tutorial/ shows cloning from a GitHub repo. There's also https://martinvonz.github.io/jj/v0.10.0/github/ which also describes how to push to a remote.

You're right that jj doesn't have support for hooks. You can work around it by creating an alias that adds the Change-Id footer. That might be similar to martinvonz/jj#1399 (comment).

(This was meant to be a reply in the thread above.)

[ppwwyyxx]

As an extra comment/suggestion, branchless has very good documentation for each command at https://github.com/arxanas/git-branchless/wiki/Command:-git-smartlog : it is HTML (has screenshots, code formatting, etc), it has usage examples, it shows common patterns, etc.
The closest thing I could find for jj is jj subcommand --help, but its boring "man-page" style is IMO harder to digest.