Re: Git an case-insensitive Mac OS X filesystem

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Sep 11, 2012, 11:18 UTC
Message-ID: <CABPQNSZznFvjCLR7A7sACf9NcESek7DmOeJcSSHFY1cGHwD2Jg@mail.gmail.com>
In-Reply-To: <vpq392og8fg.fsf@bauges.imag.fr>

On Tue, Sep 11, 2012 at 12:28 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 21 quoted lines

> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> I have stumbled upon a similar issue on Windows (which also has a
>> case-preserving filesystem), and I seem to remember the solution being
>> something to do with packed refs.
>
> Packed-refs use a format like this:
>
> $ tail -3 .git/packed-refs
> e94214ce4b8acefce06d4ea37b76ac0de11ecb2d refs/tags/v1.7.9.5
> bf68fe0313c833fa62755176f6e24988ef7cf80f refs/tags/v1.7.9.6
> 3996bb24c84013ec9ce9fa0980ce61f9ef97be4d refs/tags/v1.7.9.7
>
> so the ref name is stored within the file, not as the file name. So,
> yes, packing refs (done by "git pack-refs", called by "git gc" among
> other things) should solve case-insensitive issues.
>
> However, creating or updating refs after a pack will still create
> unpacked refs, so this solves the issue only if one of the colliding
> branches is not updated anymore.
>

Of course. In my case, the colliding refs weren't fetched from the same source IIRC.

Show 6 quoted lines

>> Perhaps we could change Git to detect name-collisions and
>> automatically pack the refs in such cases?
>
> That's a bit harder than it seems, as the idea is to avoid re-writting
> the packed-refs file for each ref update. Repacking after each colliding
> ref update could be costly in terms of performance.

Yes, but being costly in terms of performance is IMO a lot better than corrupting refs, which is what we currently do.

And it should really only be costly in the case where there's actually such a cost, on a file system where such a collision can happen.