jorio
Interactive Rebase.
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!
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 :)
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.
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.
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.
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.
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 :)
@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.
The new custom tools mitigates this, but still would be nice to have in the future; leaving this open for that reason.
I'm now using a custom command to rebase, which works well enough. Still, I'm looking forward for a slick and well integrated solution.
Having been forced back to Windows 11 for work, and therefore to SourceTree, I have been surprised to find that I much prefer editing the commit list file in VSCode over SourceTree's GUI for interactive rebase.
It's much, much faster and easier to reorganize commits. It's faster and easier to squash, especially the "fixup" -C option than doing the same in SourceTree. It's easier to review the changes. The only thing missing is that there is no ability to reword a commit directly in the commit list file, instead having to flag the commit and then reword in another editor while the rebase is actually happening. With my preferred editor I get all the text-manipulation support I am used to when coding, for free.
I have come to the conclusion that it will be very hard to beat the current text-editor DX. Therefore, I think the best option for GitFourchette is to offer a right-click option to "Interactive Rebase from Here", and run git rebase -i <hash> and call it a day.
Git-Fork offers an absolutely phenomenal interactive rebase UI which would IMO be highly worth studying for how to implement the interface in GitFourchette. I personally consider interactive rebase as the killer feature of Git-Fork, it's so well done.
Below is a screenshot I grabbed off the 'net of Git-Fork's rebase dialog.
The commits can be navigated by keyboard and each commits can toggled for (S)quash, (F)ixup, (P)ick, etc. as you'd expect, and of course a drop-down to select things for mouse-only users. Drag-n-drop is fully supported to painlessly reorder commits in addition to the keyboard controls. There's a nice dialog when (R)eword'ing a commit message.
During the rebase operation, Git-Fork tracks the state of the pending rebase and offers a "Continue Rebase" button next to its usual Commit button as well as an Abort Rebase button in the toolbar. It also has a feature to make a "backup" (makes a ref to the current commit) before the rebase, so there's easy rollback in case you really mess up.
A number of the "rebase" options are also quick actions in Git-Fork for commits, e.g. rewording a commit message or dropping a commit or such can just be a right-click in the commit history and select Reword/Drop instead of going through the full rebase flow.
