Interactive Rebase.

[l-cornelius-dol]

We use interactive rebase a lot to clean up branches, and doing so is a requirement for our workflow. This is the only feature missing that I think is of significant value to me, and I hope you'll consider implementing it, sooner rather than later. Coffees have been donated in a ~futile~ shameless attempt to bribe you!

[jorio]

I use rebase on the command line all the time as well, so I agree it'd be great to have in GitFourchette. I'm focusing on finishing a Blame feature right now; when that's done I'll look at Rebase. Thank you so much for the coffees! Really appreciate your support :)

[waldyrious]

This would be indeed quite useful indeed! A GUI could introduce welcome QOL improvements to the interactive rebase experience in the CLI, such as e.g. dragging commits in the rebase list to reorder them, renaming (i.e. retitling) commits directly from the rebase list view, or even splitting/merging commit contents as demonstrated in the Sapling video from Git Merge 2024 🤩!

Another thing that would be extremely helpful for rebasing in a GUI is the ability to grab a branch's tip and drag it over to another place in the tree, automatically bringing its relevant commits along (all the way to the merge base with the target commit), similar to the UI demonstrated a bit later in the same video.

Mind you, this kind of ideas have been floating around for many years now — back in 2015, @aspiers mentioned in his Git Minutes interview (at 54:06) how his git-deps project could be used to manipulate the graph visually, and at the time there was already a working GUI —ungit— that implemented this kind of UI, as can be seen in the demo video.

But these are possibly ambitious ideas — let me know if you'd prefer to discuss/consider them separately from the basic interactive rebase feature, and I'd be happy to open separate issues for them.

[l-cornelius-dol]

While a full GUI experience would be appreciated, even if this did little more than kick off an interactive rebase from the selected commit it would be a worthwhile improvement. Perhaps this could be a two-stage thing: first a simple integration of git's rebase, then a more powerful GUI that let you set up the rebase graphically and "press Go".

It doesn't need to be as fancy as ungit; even a list with drag-n-drop ordering and squashing, like SourceTree does, is a massive ergonomic improvement over the git command line.

[waldyrious]

Yes, absolutely! My comment was just to propose some ideas for future directions and maybe at best ensure that smaller improvements are implemented in ways that don't render such features unnecessarily harder; but I am definitely in favor of small QOL improvements as opposed to waiting for a large feature that could take a lot longer to pull off.

[l-cornelius-dol]

See #37 for alternative solution.

By the way, I have found command line interactive rebase very, very good. Better than I expected. So I would actually be perfectly happy with a convenient way to launch it instead of a GUI. In some respects rearranging the commits in a VSCode editor is easier than a GUI.

[waldyrious]

See #37 for alternative solution.

I personally wouldn't consider #37 to be a proper solution to this need. A GUI for rebase can (and IMHO should) be much more than a handy shortcut to launch the text-based UI.

By the way, I have found command line interactive rebase very, very good. Better than I expected. So I would actually be perfectly happy with a convenient way to launch it instead of a GUI. In some respects rearranging the commits in a VSCode editor is easier than a GUI.

Yeah, it is indeed very convenient and surprisingly easy to use once one gets the gist of it. Still, there are many opportunities for messing things up when editing it as free-form text, which a GUI might help guard against while keeping all the functionality — except for generic text manipulation I suppose, such as using multiple cursors and doing regex-based replacements, etc., but since the text of the rebase todo text is quite constrained, there isn't really much use for such advanced features in a way that couldn't also be implemented in a GUI (e.g. selecting multiple commits and changing their operation from pick to squash, for example), and in some cases even better (e.g. selecting non-contiguous set of commits and dragging them to the start or end of the list in one move).

Besides, a GUI could offer things that the text-based list is simply lacking, like (as mentioned above) rewording commits directly in the rebase list.

Anyway, that's a rather verbose way of saying that I, for one, would like this to be addressed separately even if #37 is implemented :)

[l-cornelius-dol]

@waldyrious : Agree on all points. Implementing #37 would go a long way to mitigating urgency on many things, though, allowing them to be more deeply considered.

I agree about directly rewording commit text using the interactive rebase commands and was very surprised to find I couldn't do that and had to instead edit each separately.