git-cola always leaves an extra commit while interactively rebasing

[marmistrz]

If we have two commits, and decide to pick, the first one and squash the second one, you cannot create a single commit out of it. Always there are two of them.

[davvid]

The best way to test this is to run the git-xbase rebase-todo editor directly, and report your findings. This way you don't need to actually do a rebase. This is implemented as an extension to git rebase where we supply a custom editor.

Create a file called rebase-todo that looks like this:

pick 638266f first commit to pick
pick b542b84 second commit to squash

Then run the git-xbase editor (assuming you keep your git clones in ~/src/:

~/src/git-cola/share/git-cola/bin/git-xbase rebase-todo

When I do this I'm able to change the "second commit to squash" to "squash" and then hit "Ctrl+Enter" (or click the "Rebase" button) to save the file. After saving it looks like this:

pick 638266f first commit to pick
squash b542b84 second commit to squash

I will note that you cannot make the very first item "squash". That's a property of how git rebase works, so the GUI checks for that gotcha and prevents users from entering an invalid state.

Let me know if this test process is a good way to exhibit the behavior you're seeing, and whether you're seeing a difference in behavior.

[marmistrz]

This works as expected, I get:

pick abe4e4a5 Add pylint, mypy and pycodestyle (former PEP8) tests to CircleCI.
squash 87e8d5c8 Further pylint fixes

just what I'd do in git.

Maybe the problem is committing? After editing in xbase, I created the commit message (this was initially # This commit is a combination of 2 commits) and clicked 'commit'. Then, nothing happened, so I clicked Rebase > continue.

It looks like it's a problem with the counter-intuitive UI behavior (and the fact that gvim was not installed on my system, so the editor was not spawned). I expected I should've edited the commit message in git-cola, not in an external editor.

Btw. git-cola should check if gvim exists and abort the rebase then.

[davvid]

Right, a missing editor can do that. We require that the configured editor blocks when called, so that git will wait for it, in case you're still seeing this after configuring an editor.

There should have been error output in the ctrl+0 "Console" log window at least.

I'll see if there's a reliable exit code we can check, or if not, maybe check for the editor ourselves (rather than relying on git).

Checking all the time means doing a $PATH search, which can be slow, so that's a strike against doing it that way. OTOH, it's probably better to alert the user that rebase "failed" (or stopped), for whatever reason, so raising these details to a popup makes sense.