My feedback after trying to switch to jj for the 3rd time

[dpc]

In random order.

There were some kinks, missing features I'd like (I opened some issues), git fetching is slow, and there is a bug making almost every jj git fetch download the whole repo from scratch for no reason. Not blockers, and I kind of expected in a young project, so 🤷 .

I think there at least be a way to opt-out out of automatically adding files. I don't miss the staging area when using jj, but I don't want it to pick some random files into a change, because something somewhere created a file in a working tree. Sure, I'm all for working copy hygiene, but I need to work with project that were not created by me and sometimes accidentally create files somewhere, and when I'm debugging it's annoying that I can't somecommand > some.out to make a temporary file. IMO, files should be tracked only after they have been explicitly "added" under revision control. After that changes in them can be tracked automatically. But it would be fine if it was an opt-out behavior.

In branchless workflow I can't figure out a good way track my in progress work. In git normally I do g b <shortdesc> and then git tracks my local branches and I can list them with g b. Yeah, I'm a heavy git user, and I have aliases for everything. But you get the picture - since I create local branches, there's a natural way to track stuff. With a branchless model, I like the fact that I don't need to make branches. But I don't know how to list "all my not-branches, against trunk and other branches (like release branches that need backports)". I tried to come up with revset formula, but it all felt short because of inability to tell local stuff from non-local things. I'm working with repos with long history, many branches pushed to remotes, cherry-picks, etc. People on Discord helpfully suggested some trivial @ against trunk() or immutable_branches formulas, which were all too simplistic. This was my main reason to give up on trying to use jj.

The git integration is kind of indecisive. IMO, in a world that standardized on git, the only way to have a chance to dethrone git, is to first be such a good git frontend that everyone just default to using it, and then attempt to abandon the underlying git internals. I've hit bunch of papercuts w.r.t. git, and while they can be solved, I'm surprised that e.g. --colocate is required and not the default, where 99% of people will be migrating from git and needing to work with git project on a daily basis. In a similiar way the jj git push, etc. could just be jj push. I realize that the project might have started frond the ground up as a different revision control system, that might internally be better, and it might be emotionally hard to make the interesting part the second place use-case, but that's just my opinion - the world does not care about technical details, only their own immediate convenience and time, and people will rather struggle for years with git UX (especially if they can bandaid it with GUIs and such), rather then go through pain of dealing with something unfamiliar. The more similiar jj is to git, the less pain, the more chance for popularity. And popularity brings users and developers.

I'm really going to miss ability to just jj edit <changeid> and get everything rebased, and the fact merge conflicts seamlessly just sit there and wait for their turn to get resolved. I really, really enjoyed it.

[ilyagr]

Thank you for some clear and interesting feedback!

IMO, files should be tracked only after they have been explicitly "added" under revision control. After that changes in them can be tracked automatically. But it would be fine if it was an opt-out behavior.

That's an interesting compromise. I might be forgetting some fatal flaw, but I don't remember thinking about it. It has some advantages:

• This will be familiar to people from the Git model. Commands like jj status can show untracked files.
• It solves first impression of jj is a failure that makes no sense. #3439, since the "file too large" error will now be reported by the jj track command as opposed to some random command.
• Potentially, some commands could be faster because they'd only need to look at tracked files. (As I write this, though, I'm thinking that perhaps this won't make much difference).

[joyously]

Long discussion of auto tracking: #323 Auto-add of untracked files screws me up every time

[ilyagr]

I tried to come up with revset formula, but it all felt short because of inability to tell local stuff from non-local things. I'm working with repos with long history, many branches pushed to remotes, cherry-picks, etc. People on Discord helpfully suggested some trivial @ against trunk() or immutable_branches formulas, which were all too simplistic. This was my main reason to give up on trying to use jj.

This aspect of jj feels a little underbaked to me as well. It's not clear to me how to improve it, but maybe thinking about a better way to define "non-local things" would help. This is what immutable_heads() is meant to be, but currently it is unreasonably hard to figure out a good value to set it to for each repo. It not only requires understanding the revset language, but also requires making some non-trivial decisions about the statement you want to make in that language.

[dpc]

Just to expand on it a bit:

I need a way to basically show me all the things that I started working on and yet not landed into trunk/releases-branches etc. Ideally it would also work for doing automatic rebase anytime trunk or release branch changed. I am able to get this with trunk() only, kinda, but with releases it is breaking down.

The mine(), author(), committer() did not seem to work for me, or at least I couldn't come up with a formula that wouldn't show me some-cherry-picks of my changes that other developers pushed as temporary dev branchs, or my own github mergequeue remotes, etc. On top of it, I have a years of history of some branches I already pushed to my fork and I don't want to bother cleaning now. But this one I should be able to overcome with some latest(...) somewhere, I hope.

I feel like there should be a formula that would work, but it's horribly difficult to come up with.

I feel like if jj could somehow track/mark changes that were created locally and then filter them with local() + had ability to mark any change as "local" (for the time you want to "import" stuff to be treated as local work). This would be a trivial thing. Seems also easy implementation-wise, but I don't really know much about the internals, so just my gut feeling.

[dpc]

#3529

[scott2000]

I think finding a good log revset was the thing I struggled with the most when switching to jj. I generally only want to see changes that I'm working on locally, and it's difficult to make a revset that only shows the changes I want. My current solution is to try to hide changes that are on remote branches which aren't also on a local branch, since I only track remote branches if I'm working on them:

[revsets]
log = "log()"

[revset-aliases]
"local_heads()" = "@ | branches()"
"log()" = "@ | trunk() | ancestors(immutable_heads().. & (remote_branches().. | ..local_heads()), 2)"

[yuja]

try to hide changes that are on remote branches which aren't also on a local branch

I use remote_branches() & ~mine() for this purpose.

[revset-aliases]
# mark all "their" branches immutable
'immutable_heads()' = 'trunk() | tags() | upstream_heads()'
'upstream_heads()' = 'remote_branches(remote="upstream") | (remote_branches(remote="origin") & ~mine())'

[revsets]
# default log revset plus descendants of the current stack
log = '@ | ancestors(immutable_heads().., 2) | trunk() | (trunk()..@)::'

[dpc]

What do you think about #3529 ?

[scott2000]

That does seem to me like it could be useful, especially the part about being able to add/remove commits from the set. I wonder if this could also be solved by topics (#3402), since you could have a "local" topic and use a revset like topic(local).

I think it also would be nice to have revsets specifically for tracked/untracked remote branches, since generally I don't want to see changes from untracked remote branches.

[dpc]

Seems like topics are more involved with inevitably larger design space. They could potentially be unified eventually.