A newbie's impressions of jj

[talpr]

Hi hi, 👋

After recently discovering jj and starting to play around with it a bit, I thought I'd write up a quick post with my impressions and some notes, in case it's useful for anyone (maintainers, future newbies, etc.)[1].

A little background, to give some context for this: Used to be a Googler, where I really enjoyed using Fig. When I went back to using Git more I tried to replicate the Fig experience in Git, with varying degrees of success. The main things I'm looking for are a "branchless" workflow and a good log (suitable for a monorepo). I discovered arxanas/git-branchless a little while ago, and it's really cool, but unfortunately it still requires quite a bit of fiddling with branches (in order to push to GitHub and open PRs). So when I saw a Reddit post by one of the Fig maintainers about a new VCS, I just had to try it out! 😁

So after using it for a whole day(!), here are some thoughts and questions that I have (for myself, mostly), in no particular order:

smartlog

I tried replicating Fig's/git-branchless's smartlog. When executing the log, I want to see all of my active branches[2], including the commit they branched off of, and the current main commit. So after fiddling around for a bit, I arrived at:

jj log -r main | \
  (:author("<my email>", heads())~:(origin/main|main)) | \
  (:author("<my email>", heads())~:(origin/main|main))-

This seems to more-or-less do what I want, with a few minor issues:

• Branches that are merged to main still show up in the graph. Maybe it just needs a ~:main to filter them out? (In Fig these just disappeared once you synced)
• main isn't "prioritized" - I couldn't figure out how to make the main commit and the different "branch bases" to show up as the left-most column in the graph, with other branches branching out of that. This makes the graph a bit messy and hard to read once I have more than 2-3 branches.
• Is there a way to show whether local branches match remote ones or if they need to be pushed?
• Not sure how to handle cases where someone else commits to my branch. Maybe I shouldn't care about the author, and just show all "local" branches?
• Not sure what the equivalent of a hg xl would be? (i.e., showing obsolete commits as well)
• Super-nitty, but as far as I can tell, there is no way to only get the "first" parent of a commit?

"Branchless" workflow

I haven't had the chance to play around with this too much yet, and I am not sure I understand exactly how jj thinks of branching and working with remotes, but a few things that "stuck out"...

jj git push seems similar to hg uploadall(?), except it only pushes branches - I think I understand why this is, but it would be really nice if the explicit branching step could be skipped. Maybe jj could just create synthetic branches for each commit and push those? Also, is there a way to push only "the current branch"? There is the --branch flag, but it seems to require a branch name. Another thing that might be nice is if there was a flag that allowed jj git push to close the current commit - having to do close them manually kinda misses out on the advertised "no index, you don't need to commit" thing. 😅

I haven't had a chance yet to properly test out the "sync" flow, but here's what I'm interested in for jj git fetch:

• Does it "update" the local main? (Pretty sure)
• Does it "update" my local branches, if they were changed on the remote? If I'm reading branches.md correctly, the answer is yes with a potential conflict.
• Does it delete local branches if they had remote counterparts but those were deleted? I am mostly thinking of merged PRs here, where the local branches are no longer needed.

Also, is there a way to just list the remotes? Plain jj git remote shows the help message, and it only show add, remove and help as sub-commands. 🤔

Tooling and integrations

Not surprisingly, since there is no actual .git repo anywhere, none of the Git tooling works with a jj repo - this includes IDEs, shell integrations (status indicators in prompt), GitHub CLI (really useful for creating PRs 😅), etc. I'm sure this will improve with time, but it is a little unfortunate for now.

Overall, though, I think I like it. Thanks for doing this, @martinvonz! 👍

[1] Please let me know if this isn't useful, though, and I'll delete the post.
[2] By "my active branches" I mean all commits authored by me, that are on branches that have not been merged to main.

[martinvonz]

So after using it for a whole day(!), here are some thoughts and questions that I have (for myself, mostly), in no particular order:

Thanks for taking your time to try it and write feedback!

smartlog

I tried replicating Fig's/git-branchless's smartlog. When executing the log, I want to see all of my active branches[2], including the commit they branched off of, and the current main commit. So after fiddling around for a bit, I arrived at:

jj log -r main | \
  (:author("<my email>", heads())~:(origin/main|main)) | \
  (:author("<my email>", heads())~:(origin/main|main))-

For something quite similar to hg xl at Google, try jj log -r 'main.. | ((main..)- & :main)'. The main.. gives you all commits that are not ancestors of main. The rest gives you the base commits for those (by finding the parents of the non-main commits and intersection those with the commits in main).

This seems to more-or-less do what I want, with a few minor issues:

• Branches that are merged to main still show up in the graph. Maybe it just needs a ~:main to filter them out? (In Fig these just disappeared once you synced)

I think those are not technically merged in the sense of being ancestors of the main branch. Rather, they're rebased to the main branch by GitHub's "Rebase and merge". I was actually already working on fixing that, but I've filed #241 now to track it. (Let me know if that doesn't seem to be the same issue, of course.)

• main isn't "prioritized" - I couldn't figure out how to make the main commit and the different "branch bases" to show up as the left-most column in the graph, with other branches branching out of that. This makes the graph a bit messy and hard to read once I have more than 2-3 branches.

I think the main branch will actually end up being on the left because the first parent of a merge should be drawn first. I suspect the issue is actually that commits from different branches can be interleaved, which often causes unnecessary crossovers in the graph. @spectral54 is actually already working on that, but I filed #242 now to track it :)

• Is there a way to show whether local branches match remote ones or if they need to be pushed?

Yes, jj branches will show any remote branches that don't match the local branches.

• Not sure how to handle cases where someone else commits to my branch. Maybe I shouldn't care about the author, and just show all "local" branches?

Probably. See if the revset I shared further up works for you.

• Not sure what the equivalent of a hg xl would be? (i.e., showing obsolete commits as well)

There's not really a concept of obsolete commits in jj, but which obsolete commits are you thinking of that you want to see?

• Super-nitty, but as far as I can tell, there is no way to only get the "first" parent of a commit?

Correct, I just haven't wanted that yet :) Feel free to file a feature request for that. Please include your use case.

"Branchless" workflow

I haven't had the chance to play around with this too much yet, and I am not sure I understand exactly how jj thinks of branching and working with remotes, but a few things that "stuck out"...

jj git push seems similar to hg uploadall(?), except it only pushes branches - I think I understand why this is, but it would be really nice if the explicit branching step could be skipped. Maybe jj could just create synthetic branches for each commit and push those?

Yes! Part of the problem is that the branch name is something others see, and, for GitHub, it's what identifies a PR (AFAIK). Perhaps we could add a mode where we push each commit to a remote branch named after the change ID. When pushing to GitHub, that might mean setting the base branch to the previous commit's branch in that case.

Also, is there a way to push only "the current branch"? There is the --branch flag, but it seems to require a branch name.

There actually isn't even a concept of a current branch yet. Without such a concept, the best we can do is to look at the branches pointing to a particular commit. I suppose we could do that and error out if there are multiple branches pointing to it. Feel free to file a feature request.

Another thing that might be nice is if there was a flag that allowed jj git push to close the current commit - having to do close them manually kinda misses out on the advertised "no index, you don't need to commit" thing. 😅

I can see that being useful when writing a small change in a single commit, but once you have more than one, you'll almost definitely want to close the commits.

By the way jj commit is an alias for jj close, in case you prefer the more familiar (but slightly inaccurate) command name.

I haven't had a chance yet to properly test out the "sync" flow, but here's what I'm interested in for jj git fetch:

• Does it "update" the local main? (Pretty sure)
• Does it "update" my local branches, if they were changed on the remote? If I'm reading branches.md correctly, the answer is yes with a potential conflict.
• Does it delete local branches if they had remote counterparts but those were deleted? I am mostly thinking of merged PRs here, where the local branches are no longer needed.

Yes, it applies the changes on the remote since last jj git fetch onto your local repo. That includes updating main and other branches (main is not treated specially), and deleting branches that were deleted. #241 mentioned above ties into this.

Also, is there a way to just list the remotes? Plain jj git remote shows the help message, and it only show add, remove and help as sub-commands. 🤔

Yes, good point. I've filed #243 to track that.

Tooling and integrations

Not surprisingly, since there is no actual .git repo anywhere, none of the Git tooling works with a jj repo - this includes IDEs, shell integrations (status indicators in prompt), GitHub CLI (really useful for creating PRs 😅), etc. I'm sure this will improve with time, but it is a little unfortunate for now.

You can actually have jj share the working copy with a git repo. If you clone using regular git clone, you can then run jj init --git-repo=.. That way you'll have both .git/ and .jj in the same parent directory. With that setup, any time you run a jj command, it'll start by importing changes from the git repo, and it'll also finish by exporting changes back to the git repo. See documentation.

Overall, though, I think I like it. Thanks for doing this, @martinvonz! 👍

Thanks!

[tp-woven]

(I'm @talpr too, just using a different account for work...)

Thanks for the in-depth response!

For something quite similar to hg xl at Google, try jj log -r 'main.. | ((main..)- & :main)'.

Hmm, not sure why, but this is showing me way too many branches... As far as I can tell, this is showing "remote" branches as well as local ones: in my repo git branch | wc -l is 5, git branch -a | wc -l is 198, jj branches | wc -l is 200. Is there any way to ignore branches that have never been checked-out locally? I would have expected branches() to do this, but AFAICT jj always creates a local branch for fetched remote branches. On a related note, is there any way to filter the output of jj branches to only show a specific branch? grep will only show the line for the local branch, without the following "detail" lines.

I think those are not technically merged in the sense of being ancestors of the main branch. Rather, they're rebased to the main branch by GitHub's "Rebase and merge". I was actually already working on fixing that, but I've filed #241 now to track it. (Let me know if that doesn't seem to be the same issue, of course.)

Ah, yes, I think you are right. I wonder how GH decides what to merge and what to rebase, but that's unrelated to jj...

I think the main branch will actually end up being on the left because the first parent of a merge should be drawn first. [...]

Yes, I think I was misreading the graph yesterday. I think I was confused by the interleaving, but also there are some weird ~s in my graph (Missing edges? Not sure what that means, exactly...) that add "bumps" in the graph:

: | | foo
o | |   08bd5e302eba 3487ea1382b6 [email protected] 2022-03-11 20:14:03.000 +09:00
:\ \ \  Merge pull request #xxx from xxxxx/xxxxx
: ~/ /
:/ /

TBH, I'm not sure why that merge commit shows up in the log in the first place, as it is an ancestor of main, and not a parent of any other commit (there is no / edge coming out of it). This is also what made me ask if there was a way to limit revsets to first parents - I thought these ~s represented other parents in a merge commit.

Yes, jj branches will show any remote branches that don't match the local branches.

Nice! Is there any way to use this information in the log template?

There's not really a concept of obsolete commits in jj, but which obsolete commits are you thinking of that you want to see?

I was thinking mostly of older "versions" of commits that were rebased (or maybe older commits belonging to the same change?). It's not something that's usually interesting, but can sometimes be handy when messing up merges. Admittedly, though, I haven't run into this situation with jj yet, so maybe it's not actually needed.

Yes! Part of the problem is that the branch name is something others see, and, for GitHub, it's what identifies a PR (AFAIK). Perhaps we could add a mode where we push each commit to a remote branch named after the change ID. When pushing to GitHub, that might mean setting the base branch to the previous commit's branch in that case.

Yes, I think something like that could work, but note that it would imply "PR per commit", which isn't very natural for GH. I'm not sure if there's a "clean" way to do multi-commit branches like this... 🤔

There actually isn't even a concept of a current branch yet. [...] Feel free to file a feature request.

Created #246.

I can see that being useful when writing a small change in a single commit, but once you have more than one, you'll almost definitely want to close the commits.

Right, I agree this is situational, that's why I suggested a flag. (But I understand if you feel this introduces more complexity and doesn't have enough value.)

By the way jj commit is an alias for jj close

Good to know, thanks!

You can actually have jj share the working copy with a git repo.

Oh, nice! I thought there might be a way to do this, but didn't have enough time yesterday to look into this.

Thanks for the thorough reply, it was really helpful! I'll try to get the log working for me properly, and then I can start using it more seriously for my project, so I'm sure I'll have more feedback then. :)

[martinvonz]

For something quite similar to hg xl at Google, try jj log -r 'main.. | ((main..)- & :main)'.

Hmm, not sure why, but this is showing me way too many branches... As far as I can tell, this is showing "remote" branches as well as local ones: in my repo git branch | wc -l is 5, git branch -a | wc -l is 198, jj branches | wc -l is 200. Is there any way to ignore branches that have never been checked-out locally? I would have expected branches() to do this, but AFAICT jj always creates a local branch for fetched remote branches.

I see. Yes, if some of those branches are descendants of main, you would indeed see them there. Maybe jj log -r 'remote_branches().. | ((remote_branches()..)- & :remote_branches())' works better for you then? However, if you also push to that remote, your own branches would become remote branches once you push them, so then they would also disappear from the output. This is an interesting problem with the automatic propagation of branches that jj does. I'll have to think more about it later.

On a related note, is there any way to filter the output of jj branches to only show a specific branch? grep will only show the line for the local branch, without the following "detail" lines.

There's no such filtering yet.

I wonder how GH decides what to merge and what to rebase

That's an option and "merge" the PR. You can choose to merge, to squash and rebase, or to just rebase.

there are some weird ~s in my graph (Missing edges? Not sure what that means, exactly...)

Those are edges that lead out of the set of commits you've selected with your revset. You can add | root to the revset if you want regular lines edges that lead down to the root commit instead (if the root commit is included, then there can be no missing edges, because all edges paths lead to the root commit sooner or later).

: | | foo
o | |   08bd5e302eba 3487ea1382b6 [email protected] 2022-03-11 20:14:03.000 +09:00
:\ \ \  Merge pull request #xxx from xxxxx/xxxxx
: ~/ /
:/ /

TBH, I'm not sure why that merge commit shows up in the log in the first place, as it is an ancestor of main, and not a parent of any other commit (there is no / edge coming out of it).

Hmm, that is weird. I don't think I've seen that before, but maybe I have just not noticed it if I've seen it. Let me know if you see it in a repo you're able to share. I couldn't find any examples in some OSS projects I looked at just now.

Yes, jj branches will show any remote branches that don't match the local branches.

Nice! Is there any way to use this information in the log template?

Kind of. By default, remote branches are shown if they're different from the local branch, like this:

$ jj log -r @-:@
@ 4c1c6006e3fc 747258e430d5 [email protected] 2022-04-26 09:38:10.000 -07:00 main
|
o ab1f2765f78e 90d42fedcd8e [email protected] 2022-04-08 13:54:49.000 -07:00 main@origin master v2.36.0-rc1  HEAD@git
~ Git 2.36-rc1

The main@origin says that that's where main branch is on that remote. But if you look at just the main branch on the topmost commit, there's no indication that some remote(s) have the branch pointing to a different commit.

There's not really a concept of obsolete commits in jj, but which obsolete commits are you thinking of that you want to see?

I was thinking mostly of older "versions" of commits that were rebased (or maybe older commits belonging to the same change?).

Ah, jj obslog will tell you that. FYI, that command may go away some day, in favor of jj op log -c <change id>, which would show the operation log filtered down to just the specified change.

Yes! Part of the problem is that the branch name is something others see, and, for GitHub, it's what identifies a PR (AFAIK). Perhaps we could add a mode where we push each commit to a remote branch named after the change ID. When pushing to GitHub, that might mean setting the base branch to the previous commit's branch in that case.

Yes, I think something like that could work, but note that it would imply "PR per commit", which isn't very natural for GH. I'm not sure if there's a "clean" way to do multi-commit branches like this... 🤔

I know :( I find it really hard to work with GitHub PRs because I'm so used to one review per commit.

I can see that being useful when writing a small change in a single commit, but once you have more than one, you'll almost definitely want to close the commits.

Right, I agree this is situational, that's why I suggested a flag. (But I understand if you feel this introduces more complexity and doesn't have enough value.)

Yes, that's my feeling right now, but feel free to file a feature request and we can see if others upvote it over time.

Thanks for the thorough reply, it was really helpful! I'll try to get the log working for me properly, and then I can start using it more seriously for my project, so I'm sure I'll have more feedback then. :)

Looking forward to it :)

[arxanas]

Perhaps we could add a mode where we push each commit to a remote branch named after the change ID.

That's what I was planning for git-branchless (if I ever got around to Github integration).

When pushing to GitHub, that might mean setting the base branch to the previous commit's branch in that case.

Unfortunately, the "base" branch scheme only works if you have a one-remote setup. If you have different pull and push remotes, then it doesn't work:

• You can open a PR from a branch on any repository to a branch on any repository;
• but you can only set the "base" for a branch to a branch on the same repository (IIUC).

So in a two-remote setup, you can't get the cascading workflow where, upon closing a PR, its descendant PR updates its base branch to make diffing easier. You can only do it when you push branches to the same repository that you're merging them into.

My plan to work around this was to introduce a synthetic base commit for each PR, which is something that jj and git-branchless can do thanks to their ability to manipulate commits in-memory, but not alternative tools for the time being. The synthetic commit would just be the squash of all the base commits in the stack with a note explaining it, so that you don't have the issue where, at the top of a stack, you have a PR with 10 commits, but 9 of them are not meaningful for the current review.

[tp-woven]

You can add | root to the revset if you want regular lines edges that lead down to the root commit instead (if the root commit is included, then there can be no missing edges, because all edges paths lead to the root commit sooner or later).

Oh, yeah, adding root to the revset really cleans the graph up, thanks! It does make the graph a tiny bit taller, but I can live with that.

Kind of. By default, remote branches are shown if they're different from the local branch [...]

Hmm, but this is only if both branches are in the chosen revset, right? I was thinking more along the lines of how Fig shows commits that need to be uploaded. I'll go ahead and open a FR for this, and we can discuss this more there?

Ah, jj obslog will tell you that.

Oh, nice, thanks!

Yes, that's my feeling right now, but feel free to file a feature request and we can see if others upvote it over time.

After giving this some more thought (auto-closing commits before push), I realized I wasn't sure I actually knew how it should behave, so that's probably an indication that this is indeed more trouble than it's worth. 😅

[arxanas]

By the way, one of the main reasons I don't use jj more is that jj log shows every commit by default, which is not useful for my workflow. I think that for approachability by new users, it should try to abbreviate things smartlog-style as the default setting, and they can customize it later to their liking. Maybe a reasonable compromise would be to show all live heads + their paths to their common merge-base?

[martinvonz]

I think that for approachability by new users, it should try to abbreviate things smartlog-style as the default setting, and they can customize it later to their liking.

Yes, good point.

Maybe a reasonable compromise would be to show all live heads + their paths to their common merge-base?

You mean the path to where they all meet? If there are un-merged release branches, that might be very far back. Maybe something like remote_branches().. | (remote_branches()..)- work well enough (until we have a config for a main branch like git-branchless does).