git-cola often interfers with git interactive rebase #99

Closed
plsamuel opened this Issue Nov 22, 2011 · 9 comments

Comments

Projects
None yet
3 participants
@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 comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Nov 22, 2011

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

ijuma commented Nov 22, 2011

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

@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Nov 22, 2011

Member

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.

Member

davvid commented Nov 22, 2011

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.

@ghost ghost assigned davvid Nov 22, 2011

@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Nov 22, 2011

Member

... 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.

Member

davvid commented Nov 22, 2011

... 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

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Nov 22, 2011

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.

ijuma commented Nov 22, 2011

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

This comment has been minimized.

Show comment
Hide comment
@plsamuel

plsamuel Nov 22, 2011

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 :)

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 davvid closed this in 6f00053 Nov 22, 2011

@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Nov 22, 2011

Member

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.

Member

davvid commented Nov 22, 2011

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

This comment has been minimized.

Show comment
Hide comment
@plsamuel

plsamuel Nov 22, 2011

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?

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 davvid reopened this Nov 22, 2011

@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Nov 22, 2011

Member

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.

Member

davvid commented Nov 22, 2011

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.

@davvid davvid closed this in c4a6a85 Nov 22, 2011

davvid added a commit to davvid/git-cola that referenced this issue Nov 23, 2011

gitcmds: Use the read-only 'git read-tree' porcelain
Avoid 'git diff' which refreshes the index and thus interferes
with concurrant git processes.

Closes #99

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

This comment has been minimized.

Show comment
Hide comment
@plsamuel

plsamuel Nov 25, 2011

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

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

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