forgit VS git-branchless

Some PR about forgit improvements

i don't like tuis that much (other than for editing text, i mean), but i also really don't like git's command line interface.

so i've been using forgit, which basically adds a really nice fzf interface for git. it really fits the way i work within a terminal (i'm a heavy fzf user).

https://github.com/wfxr/forgit

Seems like (maybe) it’s a NeoVim integration of this tool

So it is like https://github.com/wfxr/forgit only that instead of a command you can use shortcut in your terminal emulator, right?

Well, what if I told you there are tools that can improve this significantly. We are going to be looking at 2 tools today, forgit and lazygit. Both of these tools let us do many of our day-to-day git tasks, interactively and come with a LOT of keyboard shortcuts.

No, they're not.

`gcp` and `ga` are part of forgit, not OPs config. That's why searching the repo didn't find anything. I assumed they were part of OPs linked repo.

`gcp` https://github.com/wfxr/forgit/search?q=gcp

`ga` https://github.com/wfxr/forgit/search?q=ga

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.