Re: Branch Name Case Sensitivity

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 28, 2014, 14:45 UTC
Message-ID: <5310A105.50403@alum.mit.edu>
In-Reply-To: <CACsJy8B7fFBJ5ZbJDjGj4G6mx1byitC7BU4oJ3C0zq7cuv4fvA@mail.gmail.com>

On 02/28/2014 03:31 PM, Duy Nguyen wrote:

Show 27 quoted lines

> On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 02/28/2014 12:38 AM, Lee Hopkins wrote:
>>> [...] Based Michael Haggerty's response, it seems that always
>>> using loose refs would be a better workaround.
>>
>> No, I answered the question "what would be the disadvantages of using
>> only packed refs?".  Now I will answer the question "what would be the
>> disadvantages of using only loose refs?":
>>
>> 1. Efficiency.  Any time all of the references have to be read, loose
>> refs are far slower than packed refs.
>>
>> 2. Disk space and inode usage: loose refs consume one inode and one disk
>> sector (typically 4k) each, whereas packed refs consume only one inode
>> in total, and many packed refs can fit into each disk sector.
>>
>> After all, there is a reason that we have both packed refs and loose
>> refs.  The basic idea is to use packed refs for the bulk of references,
>> especially "cold" references like tags that only change infrequently,
>> but to store "hot" references as loose refs so that they can be modified
>> cheaply.
> 
> Could we have a staging place for new refs in between? Case
> sensitivity is just another limitation we hit because we rely on
> filesystem. We already have problems with having both refs foo and
> foo/bar at the same time. Not all repos are super busy and need the
> top efficiencies of loose refs.

True. Nor should most people usually need the ability to run multiple git commands simultaneously.

In fact, I've started working on a pluggable backend for reference storage. After that change, it should be easy to experiment with different combinations of loose-only, packed-only, or other (new) storage schemes that don't suffer from directory/file conflicts, etc. I haven't talked about this work on the list yet because it's still very young.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/