- lowboyIt does via snapshot.auto-track https://docs.jj-vcs.dev/latest/config/#paths-to-automaticall...
- Being responsible for something while having little/no control is so demoralizing & infuriating.
- If you're looking to model git branches as much as possible with jj bookmarks and assume that:
- the working copy has a bookmark pointing to it
- there's some ancestor with a bookmark
- there's a single linear path between the two with no other bookmarks in between
Here's an example that represents a branch containing 3 commits named "bookmark-05ff" branched off of "bookmark-6825".
In this case, the following log would get you the commit pointed to by "bookmark-6825":> jj log -r y:: -T builtin_log_redacted @ urplyywu user-482a 2025-10-23 13:24:52 bookmark-05ff a334e2e1 │ (empty) (redacted) ○ lxxtnlxw user-482a 2025-10-23 13:24:46 git_head() 7e32fa6b │ (empty) (redacted) ○ omktyuos user-482a 2025-10-23 13:24:13 7668b0bb │ (empty) (redacted) ○ ykzktoux user-7b7f 2025-10-23 13:23:47 bookmark-6825 98bfcbde │ (empty) (redacted) ~
I'm using the builtin_log_redacted output template. Normally you'd have actual bookmark names, descriptions, user, etc.> jj log -r 'latest(ancestors(@) & bookmarks(), 2) ~ @' -T builtin_log_redacted ○ ykzktoux user-7b7f 2025-10-23 13:23:47 bookmark-6825 98bfcbde │ (empty) (redacted) ~Also note this bakes in a lot of assumptions and is brittle. As many others have said, it’s not generalizable.
- Ah, yes that reading of the “work is invisible” is likely.
- > You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT
You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).
> The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I'm not 100% clear on what you mean here, but a few things that might help:
1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).
2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.
3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.
4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.
0: https://github.com/jj-vcs/jj/blob/main/CHANGELOG.md#0330---2...
- Another good sales pitch is `jj undo`[0]. It puts the repo back to previous state, regardless of what the mutative operation was. It's a powerful and simple safety net that unlocks experimentation.
It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.
0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-undo
- Your response conflates the categories of people and ignores that statements like "people..." can mean "(some|most|all) people..." in casual writing/speech. It is not a fair response.
I agree with your frustration with the framing that _all_ people who like the act and craftsmanship feel AI is negative, and the consequence that if one does like AI, then they must not like the act of craftsmanship. Many such people view it as a tool, Mitchell included.
- Your metrics for community success might be misaligned with those of the community stewards.
There's more room for interpretation in "all backgrounds, genders, and experience levels are welcome and respected equally" than with the explicit stated support for BLM, trans rights, and anti-nazi ideologies. Room for interpretation on codes of conduct make for more moderation work, allowing more undesirable behaviours to crop up.
> There's a reason most businesses/organizations don't engage in politics... even if the founders have very strong political views
Yes, but that might not be the goals of the Gleam stewards. Maybe they would rather take a moral stance even if it hurts Gleam's reach.
- I haven't seen any of the previous iterations of the conversation, nor have I had a chance to try Gleam (though it is on my short list!).
> greeting curious potential new users with any particular brand of politics (righteous or not) is possibly antithetical to the goals of the language
But it might be an important goal for the community.
- > It's impossible to prevent people who you disagree with from using a language
True, but the message on the website starts with "As a community...", and speaks to participation in the Gleam community, not the usage of Gleam as a language. And participation within a community _can_ be prevented by its stewards.
- by default, snapshots only get created on (most) `jj` invocations
the watchman integration runs snapshots on filesystem changes[0], so every time a tracked file changes on disk, a new commit is added to the evolog regardless of `jj` invocations
so say if you ran `jj status`, then changed a tracked file 3 times, and then ran `jj status` again:
without watchman you'd have 2 new evolog entries, resulting from the two `jj status` calls
with watchman you'd have 5 new evolog entries: one from `jj status`, 3 from file changes, and one from the second `jj status`
- Oops :)
- Not parent, but for me it was a couple hours of reading (jj docs and steve's tutorial), another couple hours playing around with a test repo, then a couple weeks using it in place of git on actual projects where I was a bit slower. After that it's been all net positive.
Been using it on top of git, collaborating with people via Github repos for ~11 mos now. I'm more efficient than I was in git, and it's a smoother experience. Every once and a while I'll hit something that I have to dig into, but the Discord is great for help. I don't ever want to go back to git.
And yes, jj on top of git in colocated repos (https://jj-vcs.github.io/jj/v0.27.0/git-compatibility/#co-lo...).
If you set explicit bookmark/branch names when pushing to git remotes, no one can tell you use jj.
- Zed has the least uncanny valley of any vim emulation that I've tried.
Switching is not feasible for me until they get mini.surround[0] and Flash.nvim[1], particularly Flash's treesitter mode (see screenshot of [1] to get an idea).
They work particularly well together to select semantically meaningful chunks of code and add/remove/change surrounding parens/braces/curlies/etc.
- > remember that debugging extension?
Firebug was a godsend.
- Pinning to exact versions has been supported in npm for most, if not all of its life.
That’s the usual way to do things in most teams working on app code I’ve been a part of (as opposed to library code where version ranges are preferable).
- Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.
- Nope. And not sure how you made the leap there from me giving context into my environment and equipment and how I was perceiving some text on the screen.
- Good distinction between light grey setting and perception (I was speaking to the former). Maybe on your screen/OS/browser for a given font, a setting of #000 would start at (perceived) “grey”.
And agreed that readability is a scale and it’s best to be on the “easy” end of that scale.
- Semantics, but the #5e636a (39% lightness) text of Neo4j and #1c1e21 (12% lightness) of RabbitMQ aren't what I would consider _light_ grey. That would be up in the #bbb-eee range, or 75%+ lightness (black 0%, dark grey 25%, grey 50%, light grey 75%, white 100%). And I would be surprised if designers were involved in those 2 documentation sites.
Font weight is a crucial factor of readability, and it depends on screen specifics. On my 2020 M1 mbp at ~40% screen brightness, the NNGroup link quote is quite readable. As it is on my phone.
I don't rate any designer or developer very highly if they're too precious about their "art".
The HN dead/downvoted comments is contentious for sure. I don't agree with the choice fwiw.