git-branchless VS vimagit

jj is pretty much just safer than Git in terms of the core architecture.

There's several things Git can't undo, such as if you delete a ref (in particular, for commits not observed by `HEAD`), or if you want to determine a global ordering between events from different reflogs: https://github.com/arxanas/git-branchless/wiki/Architecture#...

In contrast, jj snapshots the entire repo after each operation (including the assignment of refs to commits), so the above issues are naturally handled as part of the design. You can check the historical repo states with the operation log: https://jj-vcs.github.io/jj/latest/operation-log/ (That being said, there may be bugs in jj itself.)

I think it's unfair to call it a "thin UI layer". My own project git-branchless https://github.com/arxanas/git-branchless might more legitimately be called a "thin UI layer", since it really is a wrapper around Git.

jj involves features like first-class conflicts, which are actually fairly hard to backport to Git in a useful way. But the presence of first-class conflicts also converts certain workflows from "untenable" to "usable".

Another comment also points out that it was originally a side-project, rather than a top-down Google mandate.

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

When I was doing more hardcore dev instead of SRE'ing I settled on git branchless, was well worth the experimenting you have to do to get it into your mental model.

now that I hardly ever have 2 layer deep stacks I just settle on my go-to git client which is magit. It just takes a couple of keystrokes to do a couple of stacked rebases.

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

Yes, but due to its simplicity + extensibility + widespread adoption, I wouldn’t be surprised if we’re still using Git 100+ years from now.

The current trend (most popular and IMO likely to succeed) is to make tools (“layers”) which work on top of Git, like more intuitive UI/patterns (https://github.com/jesseduffield/lazygit, https://github.com/arxanas/git-branchless) and smart merge resolvers (https://github.com/Symbolk/IntelliMerge, https://docs.plasticscm.com/semanticmerge/how-to-configure/s...). Git it so flexible, even things that it handles terribly by default, it handles

> Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually?

Mainly it's for when you branch from A multiple times, and then modify A. This can happen if you have some base work that you build multiple features on top of. I routinely do this as part of rapid prototyping, as described here: https://github.com/arxanas/git-branchless/wiki/Workflow:-div...

`git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use.

I'm really enjoying https://github.com/jreybert/vimagit for my commit flow.

I've used vimagit for a long time (it's not in Lua, but it's pretty awesome): https://github.com/jreybert/vimagit

jreybert/vimagit a full-blown alternative to fugitive

For git i use https://github.com/jreybert/vimagit