git-cola often interfers with git interactive rebase

[plsamuel]

Most of the time, when I try to do an interactive rebase (git rebase HEAD~10 -i), and re-order/reword some commits, the operation fails if git-cola is open in the background. Here's what git rebase says:

fatal: Unable to create '/home/user/myProject/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue."

it's quite annoying that I have to close git-cola each time before doing interactive rebasing, because I do that often. I actually made a bash macro to always kill git-cola before rebases, but a more permanent solution for everyone would be better...

[ijuma]

This has happened many times to me too. It would be great to have it fixed.

[davvid]

Are you using the most recent git-cola, or is it packaged by the distribution?
I have a feeling this is due to the inotify integration.

git-cola calls git update-index --refresh which means that we rewrite the index. It may be better if git-cola were read-only in this situation and did not try to call update-index unless explicitly asked to do so (keeping the call fixes a rare edge case).

I'd be satisfied by moving the git update-index --refresh to a "Refresh the Index" menu action under Actions -> Advanced or something along those lines. Then git-cola won't be calling that in response to inotify which should also stop it from interfering with rebase.

[davvid]

... or better yet ... the 'Rescan' button should do the full update and the normal operations can just do the read-only operations. Then we don't need to add a new menu action, etc.

[ijuma]

I've been using the Fedora package for git-cola for about 2 years and the current version is 1.4.3.5. I like the proposed solution.

[plsamuel]

I had it happen to me with 1.7.1.1. I really can't speculate about what would be the best solution though, as I'm not versed into what the role of "git update-index" is, and at what times it would be most appropriate to call.

But yeah, using the index in read only when possible "sounds" good :)

[davvid]

git-cola no longer calls git update-index --refresh when scanning for the file status. It traditionally did this so that it would notice stat changes to files, e.g. if you do "touch Makefile" and don't call update-index --refresh then plumbing commands such as git diff-index HEAD (which git-cola uses) will report the file as modified.

We still call it once at startup, which is okay since that is not the part that was interfering.

Please let me know if you still encounter this problem. There's a short list of git commands that get run to check the status and they're supposed to all be read-only. If we find that this is not the case then we can ask for help on the git mailing list.

[plsamuel]

sorry, I just tried again from master and it's not resolved (simply did "git pull" then "make" then executed bin/git-cola, that should suffice right?)... wish I could help more... is there a way to get traces of what happens?

[davvid]

If you set the GIT_COLA_TRACE environment variable to '1' then it'll print commands to the shell.

... and that just pointed out what's happening. It looks like the inotify code uses a different mechanism to update the status. It ends up calling git status --porcelain, which also updates the index. You can verify it by doing 'touch foo' while running cola

env GIT_COLA_TRACE=1 bin/git-cola

The inotify code was somewhat recently changed by Karl B. and I think the git status --porcelain command came along with that change. I think we can rework it.

[plsamuel]

haven't had it happen yet, so it seems ok. Though when I do such a rebase, sometimes the "Commit Message Editor" window gets filled with a commit message, especially if I do a "reword" of a commit during interactive rebase. But at least it doesn't make the rebase lock like it used to. Tested with f97ab8d