> git tags

There are commands for manipulating tags (jj tag set, jj tag delete), and recently [1] support for fetching / pushing

[1]: https://github.com/jj-vcs/jj/pull/9279

Oh? That's incredibly recent. Thank you for letting me know. As it turns out, I just built jj from source earlier today, so ironically I should already have tags. I'll give it a try.

Rust is an example of "compiler magic" in this case.

You're right about Zig, and reading the source [1] I'm still kind of impressed how unified they made comptime / runtime.

[1]: https://github.com/ziglang/zig/blob/32a1aabff78234b428234189...

"Compiler magic" is generally used to describe things that are built into the compiler; I don't see why macros would qualify. And if they do, then why wouldn't template metaprogramming?

I would call `jj absorb` a new feature (new if coming from git, I believe the idea was taken from hg). It moves diffs into the closest ancestor that touched those files/lines. Very useful for addressing reviews, then just `jj absorb` and watch them get squashed into the correct location.

This gets even better with octopus merges (known in the jj community as "megamerges"): open up 5 branches at the same time, address minor tweaks in any number of them, and `jj absorb` the content into the right parent branch.

I do use git absorb, but its true, you have to install it.

I have never tried git absorb across merges, no clue if that works.

It does not, or at least not very well. Merges can't be rebased without replaying conflict resolution; since Git lacks a first-class concept of conflicts, that becomes a manual process.

Moreover, jj should be able (I haven't explicitly tried this) to autogenerate the conflict resolution in the `jj absorb` case, since it knows what the final post-merge state should be.

...no? On all counts.

`jj ignore` is not a command. [1]

There is no such thing as `.jjignore` files [2], [3].

`--no-snapshot` is not a flag, neither on `jj edit` nor in general. Additionally, it doesn't make sense conceptually --- `jj edit` changes the working copy, which will then propagate changes to the selected commit every time you edit a file.

If you want to check out an old commit without amending it, you `jj new` on top of it. If you end up making changes that you don't care about, you can `jj abandon` them.

[1]: https://jj-vcs.github.io/jj/latest/cli-reference/

[2]: https://github.com/jj-vcs/jj/issues/3525

[3]: https://jj-vcs.github.io/jj/latest/working-copy/#ignored-fil...

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.

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?

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.

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

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

> 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.

> > if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p.

> You are right with the outcome but wrong about why. `jj abandon -r q` would turn `r --> q --> p` into `r --> p`

Well, it can do two things. Given: `r(f3) --[e3]--> q(f2) --[e2]--> p(f1)`

`jj abandon -r q` makes `r(f1+e3) --[e3]--> p(f1)`, as if you had rebased `r` onto `p`.

`jj abandon -r q --restore-descendants` makes `r(f3) --[e2+e3]--> p(f1)`, as if you had squashed `r` into `q`.

Ah intriguing, I didn't know about `--restore-descendants`, and I can see how that makes it feel like you're operating on edges, even if you're passing a revision in. Thanks!

You may be interested in the semi-standard `jj tug` alias [1], that moves "the most recent" bookmark up to `@-`

[1]: https://github.com/jj-vcs/jj/discussions/5568

This is excellent, thank you! I've had my own `jj bm` (for "bookmark move") alias to do this, but that implementation is way better.

Amazing alias I've adopted. Should be standard.

This is great, thanks.