FWIW the concept of undo/redo is at least novel. Agree it’s not worth paying for though, lazygit does all of this (even undo/redo) for free, as well as… the rest of git workflow.

(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!

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

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.

> many people will pay for a GUI interface

Then many people should purchase SmartGit client. Which supports more of the same thing (with couple more clicks, granted) but also has a proper tree view. Also supports linux ffs.

Never working with git without it again.

Looking at the docs I'm not sure what functionality that adds over git. It seems like just a GUI, no extra abstractions for the complicated operations. E.g. modifying older commits[1] still looks to require manually branching, resetting, making the modification, rebasing/cherry-picking from the previous branch, fixing any conflicts, and then deleting the previous branch. That's pretty shitty for a wrapper, it should just be "right click the commit, click modify, make edits, resolve any conflicts". The porcelain shouldn't expose the plumbing so much!

[1] https://docs.syntevo.com/SmartGit/Latest/HowTos/Modifying-th...

> "right click the commit, click modify, make edits, resolve any conflicts"

I don't know why the docs are this way, it's literally that. Maybe old version or something. This page is closer to the truth.

https://docs.syntevo.com/SmartGit/Latest/Manual/GUI/Branch/R...

You can download it and check it out, they have trial licenses.

I’m happy with Jetbrains conflict resolution, but the I’ve never tried SmartGit for comparison.

It would take a lot for me to move because I already pay for Jetbrains IDE.

I don’t think SmartGit will elevate you that much but JetBrains IDEs and SmartGit are the only two tools I pay for and have for 8 years with no regrets.

I already posted in this thread but I just love these two tools and wish more people knew about both of them.

+1 for SmartGit. It's much more intuitive and flexible than the JetBrains UI, which still inherits so much terminology and behavior from its "unified" view that includes being able to handle Perforce changelists. It's a bit of a mess and generally trips new users up more than it helps. If you're comfortable with it, then good for you but I've had a lot of students not being able to grok it really well.

I used to feel that way about JetBrains, but I don’t notice those abstractions anymore. IDK how much of it is the iterative changes they have made over the years vs me getting used to it.

I'm just going to drop a casual shout-out to jujutsu[1]. It elegantly solves things like rebase/merge conflicts (and solves a lot of other sharp edges in git at the same time). It eliminates the need for WIP commits, stashing, and a host of other workflow bandaids we’ve all internalized. Best of all, it’s 100% git-compatible, so you can mix and match jj and git commands whenever needed, your coworkers never need know you're using something else, and even if it never gain critical mass you can still just use it and have superpowers while everyone else lives in the metaphorical stone age.

It is one of those rare birds that is both more powerful than the tool that it replaces while also being drastically easier to use. I am (was?) a git power user. It took me all of a day to replace git with jj and generously the rest of the week to become essentially as fluent. I will never go back.

Chris Krycho's post[2] was what originally sold me and I hope it sells you too.

[1] https://github.com/martinvonz/jj

[2] https://v5.chriskrycho.com/essays/jj-init/

I'll add that while `jj` itself is a CLI, people have made GUIs on top of it that allow for drag and dropping of commits:

https://github.com/gulbanana/gg https://www.visualjj.com/

Came to plug jj as well.

Steve klabnik's tutorial is excellent as well. https://steveklabnik.github.io/jujutsu-tutorial/introduction...

Yeah I've heard of it. I was put of by the removal of the staging area which I think is one of Git's nicest features.

Maybe I'll check it out. Deferring conflict resolution is definitely a killer feature.

This was the exact thing that kept me from trying it sooner. I wish I’d realized that that doesn’t imply an “everything gets committed” approach.

It’s trivial to split a change in two. So your working copy is constantly snapshotted, and when you’re finished you `jj split` and choose the parts you want to keep. The rest is moved out into a new change.

That workflow is in practice basically identical to the `git add -p` one, though the terminology is a bit different and there are some greatly simplifying changes under the hood.