git-branchless VS git-stack

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.

What happens is you work somewhere that has stacked diffs and suddenly you learn how to shape your diffs to make them easy to review. Thinking of how folks will review your code in chunks while writing it makes it cleaner. Having small but easy to read diffs makes reviews faster and helps junior devs learn how to review.

Sometimes this doesn’t happen in which case you end up need to split your commit at the end. This is where git utterly fails. You end up needing git split and git absorb to make this productive.

Git split let’s you select which chunks in a commit should belong to it and then splits that into a commit and then you do it again and again until you have lots of commits. You’ll still need to probably test each one but the majority of the work is done

Git absorb takes changes on the top of your stack and magically finds which commit in your stack the each chunk should belong to and amends it to the right commit

You also need git branchless https://github.com/arxanas/git-branchless as it lets you move up and down the stack without needing to remember so much git arcana.

I'm not seeing a git compatibility layer? So I think it's a neat project, but I probably won't try it because nearly all code is rooted squarely in git. Even if Pijul is perfect, you'd need to convince everyone else to use it.

Nevertheless, the increased interest in moving to patch based workflows from branch based ones is great. There's a lot of similar tools here (https://github.com/gitext-rs/git-stack/blob/main/docs/compar...) which I refer to infrequently.

Personally my favorite tool for living-with-the-reality-that-is-branches is git-machete (https://github.com/VirtusLab/git-machete).

This is huge. I've wasted so much time on this, I wrote my own tool. No idea how thoroughly they've implemented this though (what all corner cases does it update or not)

> Probably some arcane git magic to (interactively) rebase branch

There is not really a command for that yet, short of adding a bunch of `exec` steps to your interactive rebase manually. See https://news.ycombinator.com/item?id=32217204 for an upcoming command.

You might enjoy using https://github.com/gitext-rs/git-stack, which specifically tries to let you manage stacked branches locally while not exposing tons of PRs to your coworkers.

git-branchless itself also lets you manage stacked branches in various ways. For example, you can do `git checkout `, `git commit --amend`, and then `git restack` to rebase all the descendant branches sensibly. You can use it on the local side of things only and then use Github PRs as normal.

I've been using termtree in my applications but I'm needing something more like git log --graph for git stack but haven't found a general purpose one (there is an implementation inside of git branchless) and haven't had a chance to make one myself.

Got a comparison of tools in this space at https://github.com/gitext-rs/git-stack/blob/main/docs/comparison.md

I try to keep the number of branches down but git-stack provides something like git log --graph that collapses branches from other users and old branches, keeping the main view clean.

Checkout https://github.com/gitext-rs/git-stack/blob/main/docs/compar... (note, the tool hosting this page is not included but as the author).

As the author of git stack, with all relevant biases, I recommend

- git stack for automating what you are already doing

- git branchless for more power at the risk of incombatibilities because its only as good as the data fed to git hooks

- jj if your open to something very different