lowboy

    > 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)
    ~

In this case, the following log would get you the commit pointed to by "bookmark-6825":

    > 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)
    ~

I'm using the builtin_log_redacted output template. Normally you'd have actual bookmark names, descriptions, user, etc.

Also note this bakes in a lot of assumptions and is brittle. As many others have said, it’s not generalizable.

Comment · 1 year ago

Ah, yes that reading of the “work is invisible” is likely.

Comment · 1 year ago

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

1: https://social.jvns.ca/@b0rk/111709462585184810

Comment · 1 year ago

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

1: https://jj-vcs.github.io/jj/latest/operation-log/

Comment · 1 year ago

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.

Comment · 1 year ago

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.

Comment · 1 year ago

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.

Comment · 1 year ago

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

Comment · 1 year ago

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`

0: https://jj-vcs.github.io/jj/latest/config/#watchman

Comment · 1 year ago

Oops :)

Comment · 1 year ago

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.

Comment · 1 year ago

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.

0: https://github.com/echasnovski/mini.surround

1: https://github.com/folke/flash.nvim

Comment · 1 year ago

> remember that debugging extension?

Firebug was a godsend.