Re: Branch Name Case Sensitivity

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 27, 2014, 21:00 UTC
Message-ID: <530FA77B.2030707@alum.mit.edu>
In-Reply-To: <CAJHY66H2M2aQvQ8MLN7XB4uYiFohRfhhsXhd56hwDR5qMGi6Tg@mail.gmail.com>

On 02/27/2014 09:37 PM, Lee Hopkins wrote:

Show 13 quoted lines

>> Perhaps git-{branch,tag}.txt and possibly gitrepository-layout.txt
>> in Documentation/ may need a new "*Note*" section to warn against
>> this.
> 
> A little more documentation never hurt anyone :).
> 
>> Or we can possibly trigger this function at the the of
>> "checkout -b" or "fetch" commands ?
>> Only when core.ignorecase == true ?
> 
> This would essentially make git always use packed-refs when
> core.ignorecase == true, correct? Are there any downsides to always
> using packed-refs?

There are at least two reasons I can think of:

1. Efficiency: any time a reference changes, the whole packed-refs file
would have to be read and written as opposed to a single, small
loose-ref file.

2. Lock contention: two processes can modify loose references at the
same time without contending with each other.  If they always wrote the
packed-refs file, there would be more lock contention (which in the git
world means that one of the processes would fail).

Whether these are concern for a single user using a local git repository (as opposed to git running on a server) mostly depends on how many references you have. With a hundred references you would probably not notice any difference. With ten thousand you probably would. Somewhere in between lies the pain threshold.

Michael

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