New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git-cola always leaves an extra commit while interactively rebasing #721

Closed
marmistrz opened this Issue Aug 17, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@marmistrz

marmistrz commented Aug 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Aug 20, 2017

Member

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.

Member

davvid commented Aug 20, 2017

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 comment has been minimized.

Show comment
Hide comment
@marmistrz

marmistrz Aug 21, 2017

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.

marmistrz commented Aug 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Aug 22, 2017

Member

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.

Member

davvid commented Aug 22, 2017

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.

@davvid davvid added the usability label Aug 22, 2017

davvid added a commit to davvid/git-cola that referenced this issue Aug 22, 2017

interaction: add a helper for reporting command errors
Related-to: git-cola#721

Signed-off-by: David Aguilar <davvid@gmail.com>

@davvid davvid closed this in a5d3973 Aug 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment