On Tue, Sep 11, 2012 at 12:28 PM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Erik Faye-Lund <kusmabite@xxxxxxxxx> 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. >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html