search

rowanj / gitx

Fork of Pieter's nice git GUI for OS X. Includes branch/tag sidebar and various fixes. Current development focus is on removing legacy git command line usage in favour of libgit2 and objective-git.
http://rowanj.github.com/gitx
Other
2.15k stars 204 forks source link

GitX appears to be (briefly) creating lock files, interfering with command line use. #443

Open bonkydog opened 9 years ago

bonkydog commented 9 years ago

(Sorry for this almost comically vague bug report, but...)

When I do multi commit rebases on the command line, often the process gets interrupted with this message:

fatal: Unable to create '/Users/bonkydog/my-project-directory/.git/index.lock': File exists.

This only happens when GitX is running. If I close GitX, it never happens.

Is GitX possibly creating, then removing lock files while it sits there, possibly as some kind of polling behavior?

dragos commented 9 years ago

I have seen this as well. Funny enough, it never happened on my old machine, but happens almost every time on my new Mac. Extremely annoying.

bonkydog commented 9 years ago

Maybe a Yosemite thing?

josharian commented 9 years ago

This happens to me a lot as well. I am in the habit of closing gitx, doing my rebase, and then reopening gitx.

tiennou commented 9 years ago

Workaround: disable the autorefresh setting in preferences ("Watch for changes in repository") and do it manually when you switch back to GitX (via ⌘R). This uses the user as some kind of mutex but that's the only way to do rebases without weirdness happening.

grum commented 9 years ago

Maybe an option to only automagically refresh when the window has focus? Would save me a lot of ⌘R'ing :D

tiennou commented 9 years ago

What would happen is you start your rebase on the CLI, switch to GitX because OH MY GOD I CAN'T STOP IT you want to check your probable next step/refer to history/whatever and boom. Your rebase see the lock, and you're back at square one.

rbq commented 9 years ago

I think had the same problem but it automagically fixed itself with one of the last Git 2.5.x releases when they introduced some retry mechanism?