lowboy

8 か月前議論

It does via snapshot.auto-track https://docs.jj-vcs.dev/latest/config/#paths-to-automaticall...

8 か月前議論

Being responsible for something while having little/no control is so demoralizing & infuriating.

9 か月前議論

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

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

lowboy

9 か月前議論

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

lowboy

9 か月前議論

> 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

lowboy

9 か月前議論

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/

lowboy

10 か月前議論

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.

lowboy

12 か月前議論

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.

lowboy

12 か月前議論

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.

lowboy

12 か月前議論

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

lowboy

12 か月前議論

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

lowboy

昨年議論

Oops :)

lowboy

昨年議論

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.

lowboy

昨年議論

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

lowboy

2 年前議論

> remember that debugging extension?

Firebug was a godsend.

lowboy

2 年前議論

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

lowboy

2 年前議論

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.

lowboy

2 年前議論

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.

lowboy

2 年前議論

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.

lowboy

2 年前議論

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.

投稿

Tell HN: ErgoDox mechanical ergo keyboard on sale again

The ErgoDox keyboard a year in, and why you should get one

コメント