[nchmy]

Thanks for this! Just yesterday I decided to finally start really using jj with real work, whereas I had only fiddled around with it a few times while following tutorials over the past year.

One suggestion - reverse the direction of the arrows: q->r rather than q<-r

[justinpombrio]

Thanks for the kind word!

Unfortunately the arrows are kind of confusing regardless of which way they go. You're suggesting they point forward in time, from the old commit to the new commit. The way they're drawn is the direction of the reference: a commit points at its parent. The argument in favor of each way the arrows could go feel about equally strong to me, and my understanding is that the convention in repo diagrams is for arrows to go in the direction of the reference, so that's what I went with.

[vermilingua]

Something I've worried about trying to switch to jj: is there a chance that using it will cause noticable artifacts or issues in the upstream git repo? We're quite strict on tooling in my team and I don't want to get to a state where I can't digest the jj changes back into normal git commits for pushing.

There's plenty about how you can use jj as a replacement but no clear guidance on what upstream commits will actually look like if you use it.

[notmywalrus]

The blockers for many are:

- No support for LFS

- No support for hooks (precommit, etc)

- No? Bad? support for submodules

- No? Bad? support for line ending styles

If you don't care about those, you _should_ be able to use jj completely "undetected". It does encourage rewriting history more than some git workflows like.

In terms of issues in the git repo -- there shouldn't be any. jj uses git as a backend, all commits are stored as git commits, etc. If you colocate the repo, you're able to use git commands directly.

[vermilingua]

Awesome, cheers. It also seems to encourage merges over linear history (I guess because the history of "bookmarks" is deemphasised), is a linear history still achievable?

[ljm]

I think it's exactly the opposite and the mental model of branching is counter-productive with jj. It's much more in line with trunk based development and the idea of managing 'stacks' of changes (kinda like merge trains where multiple smaller PRs in turn depend on each other).

If you had multiple people working on a branch and only some were using jj, then those not using jj would likely have issues with all of the rebasing and force pushes that happen behind the scenes to keep the history clean.

If you were to enforce linear history (like in GitHub) and used rebase merges exclusively then I think it's ideal, especially in terms of reviewing smaller, incremental changes rather than huge pull request diffs.

[notmywalrus]

I find it encourages linear history more by making rebasing easier. Definitely possible, the jj project itself uses a linear history.

[steveklabnik]

I use jj and enforce a linear history on my upstream github.

[steveklabnik]

> No? Bad? support for submodules

No support in the sense that jj won't do anything with them, but you can collocate the repository and use git to deal with them and it's fine.

> - No? Bad? support for line ending styles

That's a No, currently, yeah.