notmywalrus

> 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

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

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.

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

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

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.

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

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