Re: [PATCH v3 0/4] refs/files: fix issues with git-fetch on case-insensitive FS

[Junio C Hamano <gitster@pobox.com>]

Karthik Nayak <karthik.188@gmail.com> writes:

>> I've noticed another issue though, at the moment it's possible to create
>> a ref like `refs/heads/foo.Lock`. I can image this gives issue when the
>> remote has `refs/heads/foo` and `refs/heads/foo.Lock` and you pull those
>> in on a case-insensitive FS. Unfortunately I wasn't able to verify this.
>> But anyhow, I don't think that any reason to hold back on this current
>> patch series. I approve.
>
> We don't fetch locks from remote. The locking mechanism is simply a
> construct used to update files locally in race-free manner. Locking a
> file ensures no other concurrent writes can happen.

I am not Toon, but I think Toon meant "foo.Lock" to be a funnily
named but a valid branch the remote has.

Doesn't the remote advertise refs/heads/foo and refs/heads/foo.Lock
in such a case?  And we can ask for both of them.  When updating
foo, we would locally create "refs/heads/foo.lock" and then rename
it to refs/heads/foo", right?  I think Toon's point was what happens
when the fetch of "foo.Lock" from there somehow has completed first.
Or we can simply fetch foo.Lock branch and then foo branch in a
separate invocation of "git fetch"---now wouldn't the second
invocation have trouble creating the lock file foo.lock for foo on
certain filesystems?

> In-short when you fetch references, the prepare stage of the reference
> transaction will create the necessary lock files. This locks in the
> updates with guarantee that no other process can update/create the refs.
> The commit phase simply removes the lock files post updating the refs.