rfc: Add dedicated rebase UI?

[fmuellner]

Unlike commits, the todo list of an interactive rebase is not free-form. We could therefore do better than just popping up an editor like git does, and instead have a dedicated UI:

Does that look like a good idea?

(I'm about to go on holiday, so may have some time for some fun hacking)

[sonnyp]

I had the same idea but was worried it would provide a lesser experience regarding keyboard navigation, specially if I enable GtkSourceView Vim emulation.

Perhaps it could be a view switcher?

Anyway – I like the idea and would love if Commit could also provide some tooltips to help beginners understand what's going on there.

Related https://gitlab.gnome.org/GNOME/gitg/-/issues/4

[fmuellner]

I had the same idea

Heh, I didn't claim it was an original idea :-)

was worried it would provide a lesser experience regarding keyboard navigation, specially if I enable GtkSourceView Vim emulation.

I'm less worried there.

Keyboard navigation of lists is already pretty good out-of-the-box (tab or up/down arrows to move between rows, enter or space to open the popover with the available actions). There is no built-in support for moving rows, but I don't expect that to be harder than shortcuts to move lines of text.

Vim bindings come in handy for stuff like 0cw squash as that's easier than HomeShiftCtrl → squash, but then you don't need either if the only navigation you need is up/down.

There's one thing I hadn't thought of: Moving a group of commits. That can currently be done by selecting multiple lines and using the shortcuts. I don't see an obvious GUI replacement :-(

Perhaps it could be a view switcher?

Mmh, that would certainly complicate things (not just in terms of UI).

With a GUI-only approach, you just have to parse the todo once to create the UI, and write out the final state if the rebase is confirmed.

A view switcher requires to have both a text buffer and a list, and keep both in sync (in either direction, as changes to the text buffer should be reflected in the UI and vice-versa).

[sonnyp]

Heh, I didn't claim it was an original idea :-)

I meant it in a way that I also thought it was a good idea 🙌

A view switcher requires to have both a text buffer and a list, and keep both in sync (in either direction, as changes to the text buffer should be reflected in the UI and vice-versa).

I'm happy to implement that later or fallback to a preference.

Let's default to the GUI anyway 👍

[oleastre]

Hello, I've just gone through a big rebase today, and while it's easy to reorder commits, it's quite not easy to replace a pick with a squash, reword, edit, ...
I had a look at the keyboard short cuts hoping to have some rebase specific one there, but without luck.
A quick win for me, that would not need a big UI change, would be to have shortcuts that just replace the first line word with an other one. for example:

Ctrl+p => pick
Ctrl+s => squash
Ctrl+e => edit
Ctrl+r => reword
Ctrl+d => delete

If multiple lines are selected, loop over each line and apply the same replace strategy.

[coreyberla]

Another somewhat related complication is that "Abort" appears during an interactive rebase, which is confusing to me because clicking "Abort" doesn't actually abort the rebase. Not sure if it makes sense to changing the wording globally or just in a separate rebase window.