[Cykelero]

(Retcon dev here)

lazygit is really cool, and is a lot more full-featured than Retcon. But, the core "rewrite with zero friction" feature of Retcon is still unmatched, I think.

For instance: while lazygit does allow you to reorder commits without entering a separate mode, that's only if each move is conflict free. If you have two commits that need to both be moved at once, then in lazygit, you'll have to resort to a regular interactive rebase (so, with the separate planning and execution steps, no undo or preview along the way, etc).

In Retcon, if a commit move results in a conflict, that doesn't matter; you can keep making changes to your history anyway, and then resolve any remaining conflicts when you're ready. It makes the workflow super fluid.

There's probably still a ton Retcon could learn from lazygit/magit/jj, though!

[ilyagr]

> In Retcon, if a commit move results in a conflict, that doesn't matter; you can keep making changes to your history anyway, and then resolve any remaining conflicts when you're ready.

I didn't realize Retcon could do this from the website, nice!

I wonder how similar your approach is to [jj's approach to conflicts]; whether you reinvented the same way of modelling conflicts in the repo or use a different one. (See also the link to the technical docs from that page)

https://gitbutler.com/ also [borrowed this idea] from jj.

[jj's approach to conflicts]: https://martinvonz.github.io/jj/latest/conflicts/

[borrowed this idea]: https://blog.gitbutler.com/fearless-rebasing/

So, there are several tools exploring these ideas, but there are interesting differences in (for example) how close to Git each of these approaches stays.

[Cykelero]

Thanks for the link; jj's approach seems really solid.

Retcon is pretty different: during a rebase, the state of everything is only stored in RAM, not serialized to the repo. So while you can postpone resolving conflicts until you're done putting commits in place, you do have to do so before you go do something else in your repo.

The RAM representation is basically a list of commits (well, commit-likes), what I call a virtual history. It's the history you want to get to, but that's not currently representable with a regular, physical Git history.