Hacker News Reader

Comment by remram | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com