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

[bonkydog]

(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]

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]

Maybe a Yosemite thing?

[josharian]

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

[tiennou]

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]

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

[tiennou]

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]

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?