From: Michael Haggerty Date: Fri, 28 Feb 2014 14:45:25 GMT Subject: Re: Branch Name Case Sensitivity Message-ID: <5310A105.50403@alum.mit.edu> In-Reply-To: On 02/28/2014 03:31 PM, Duy Nguyen wrote: > On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty 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/