Hacker News Reader

Comment by eawgewag | Hacker News Reader

JJ is incredible. Highly recommend it. I can't put into words what a game changer it is for my workflow.

The only thing I reach for for git now is `bisect` when I need to debug an oncall issue.

I have never really made bisect a part of my workflow, but something I believe would work well with just jj is making two workspaces before and after the issue, and iteratively walking their working revisions toward each other. That has the advantage of being able to run both versions simultaneously easily.

What do you mean both versions? They are all different versions.

You have N versions between your endpoints, and you test log(N) of them. You don't test any single version more than one time.

For certain applications and bugs it may be helpful to see a version of the application with the bug running side by side with a version without the bug. By "both versions" I meant the versions checked out in both workspaces. See: https://martinvonz.github.io/jj/latest/working-copy/#workspa...

But you don't know in advance whether a given version has the bug, that's kind of the reason for bisecting. Or do you mean you have 3 versions side-by-side: the last-known-bad, last-known-good, next-unknown-to-test?

FYI git has "worktrees": https://git-scm.com/docs/git-worktree

I mean making two workspace, and iteratively walking them towards each other in the revision tree, until to you cross the revision that introduced the bug (either both instances show the bug or neither does). There isn't really a reason to have three workspaces. If you want to mark where you were so you don't forget, you can just use bookmarks, but really you can just look at the operation log to see where you were.

You can run the tests on each commit in parallel if you're okay with wasting CPU time to save wall-clock time. git-branchless can speculatively run linear or binary search in parallel up to a user-specified number of jobs [1], and I'd like it add it to jj someday, as it's one of the features I miss most.

(To run the tests in parallel, git-branchless provisions its own worktrees. For binary search, it speculatively executes the search for the potential success and failure cases; when the number of jobs is a power of 2, this partitions the search space evenly.)

[1]: https://github.com/arxanas/git-branchless/wiki/Command:-git-...

This is a nice reminder for me to check it out.

I've liked Phabricator, and Google's internal variant of Mercurial in the past (and have always despised GitHub's PR=branch model). Sounds like Jujutsu might be right up my alley.

Reply on news.ycombinator.com