Regular Rebase Failure

About two weeks ago I started getting a regular rebase failure. I get this error several times a day and at least once a day I lose work to it. --- fatal: Unable to create '/Users/asteel/path/to/repo/.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.

Could not apply 71a... --- The weird part is that the file does not exist

Any ideas? Thanks!

On Tue, Apr 21, 2015 at 10:16 AM, Adam <adamgsteel@gmail.com> wrote:

Which git version are you using?

Searching through the code base there are only 3 occurrences of "Unable to create" matching the capitalization of the letters. (we have many more error messages where the U is lower case)

The first occurrence is in refs.c create_symref
    if (rename(lockpath, git_HEAD) < 0) {
        error("Unable to create %s", git_HEAD);
        goto error_unlink_return;
    }

The other 2 occurrences are in the lockfile.c so any place using lock files may trigger that error.

Not anymore when you're looking I guess, as git creates and deletes a lock file for the index quite frequently. Also when a git command shuts down roughly as expected (such as when calling a die(error message) as opposed to being terminated by the operating system), then the exit handler makes sure to remove all the lock files it held.

[+mailing list]

On Tue, Apr 21, 2015 at 11:20 AM, Adam <adamgsteel@gmail.com> wrote:

We should loop in the maintainers of the Apple Git version, they'd know what changed in git about two weeks ago. I have no idea who that is though.

Complain at the right people so it gets fixed. ;)

On Tue, Apr 21, 2015 at 11:34:37AM -0700, Stefan Beller wrote:

You can get some releases from:

  http://www.opensource.apple.com/tarballs/Git/

and at least view the diff against stock git. But they do not seem to have updated that in some time (the latest release is Apple Git-48, based off of v1.8.5.2).

It would be nice if they kept that up to date (actually not just nice, but required by the GPL[1]). It would be nicer still if they actually published their patches with real commit messages, or better yet actually engaged with upstream to work on fixes or enhancements.

This isn't strictly relevant to the discussion at hand, but in case any Apple Git folks do see this, perhaps it will serve as a gentle nudge.

-Peff

[1] By the GPL, they don't strictly need to publish the source; they
    just have to make an offer to provide it on request. But given the
    existence of opensource.apple.com, I think their strategy is to just
    publish everything, and they have simply let updating that site fall
    behind the binaries they are pushing. Or maybe they have switched to
    an alternate site that I don't know about.

[+mailing list, so others can also chime in and have an answer/opinion]

On Mon, Apr 27, 2015 at 10:07 AM, Adam Steel <adamgsteel@gmail.com> wrote:

Is the repository located on a mounted network share, or could other users be accessing it via a network mount? We had a similar problem recently on a new Jenkins VM instance which had only NFS-mounted storage available. I don't remember if it was Git that was failing on there, and I wasn't directly involved in solving the problem. But while researching the issue I found ominous warnings about the dangers of file-locking on remote shares [1]. Which is to say, I don't know much, but I heard a rumor... :-)

Perhaps this is old news and already well covered in Git.  But I am curious...

[1] http://0pointer.de/blog/projects/locking.html

Nope, this is local on an OSX system with only one user, no local network. This happens about every third interactive rebase.

On Wed, Apr 29, 2015 at 9:14 AM, Phil Hord <phil.hord@gmail.com> wrote: