Regular Rebase Failure

Regular Rebase Failure

[Adam]

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!

Re: Regular Rebase Failure

[Stefan Beller]

On Tue, Apr 21, 2015 at 10:16 AM, Adam <adamgsteel@gmail.com> wrote:
> 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.

Which git version are you using?

> ---
> fatal: Unable to create '/Users/asteel/path/to/repo/.git/index.lock': File
> exists.

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.

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

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.

>
> Any ideas? Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regular Rebase Failure

[Stefan Beller]

[+mailing list]

On Tue, Apr 21, 2015 at 11:20 AM, Adam <adamgsteel@gmail.com> wrote:
> I'm using git version 2.3.2 (Apple Git-55).

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.

>
> That explains why I can't find the index.lock file, since the error that was
> thrown deleted it. I'm still not sure what to do about this, though.

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

>
> Thanks for responding.
>
> Adam
>

Re: Regular Rebase Failure

[Jeff King]

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

> [+mailing list]
> 
> On Tue, Apr 21, 2015 at 11:20 AM, Adam <adamgsteel@gmail.com> wrote:
> > I'm using git version 2.3.2 (Apple Git-55).
> 
> 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.

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.

Re: Regular Rebase Failure

[Stefan Beller]

[+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:
> Stefan,
>
> So I switched git versions.
>
> $ git --version
> git version 2.3.1
>
> I'm still getting the same regular rebase failures.
>
> ---
>
> fatal: Unable to create
> '/Users/asteel/Repositories/rails-teespring/.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.
>
> ---
>
> Any ideas?
>
> Adam
>
> On Tue, Apr 21, 2015 at 12:34 PM, Stefan Beller <sbeller@google.com> wrote:
>> [+mailing list]
>>
>> On Tue, Apr 21, 2015 at 11:20 AM, Adam <adamgsteel@gmail.com> wrote:
>>> I'm using git version 2.3.2 (Apple Git-55).
>>
>> 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.
>>
>>>
>>> That explains why I can't find the index.lock file, since the error that was
>>> thrown deleted it. I'm still not sure what to do about this, though.
>>
>> Complain at the right people so it gets fixed. ;)
>>
>>>
>>> Thanks for responding.
>>>
>>> Adam
>>>

Re: Regular Rebase Failure

[Phil Hord]

> On Mon, Apr 27, 2015 at 10:07 AM, Adam Steel <adamgsteel@gmail.com> wrote:
>> Stefan,
>>
>> So I switched git versions.
>>
>> $ git --version
>> git version 2.3.1
>>
>> I'm still getting the same regular rebase failures.
>>
>> ---
>>
>> fatal: Unable to create
>> '/Users/asteel/Repositories/rails-teespring/.git/index.lock': File
>> exists.

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

Re: Regular Rebase Failure

[Adam Steel]

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:
>> On Mon, Apr 27, 2015 at 10:07 AM, Adam Steel <adamgsteel@gmail.com> wrote:
>>> Stefan,
>>>
>>> So I switched git versions.
>>>
>>> $ git --version
>>> git version 2.3.1
>>>
>>> I'm still getting the same regular rebase failures.
>>>
>>> ---
>>>
>>> fatal: Unable to create
>>> '/Users/asteel/Repositories/rails-teespring/.git/index.lock': File
>>> exists.
>
> 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