On 02/28/2014 03:31 PM, Duy Nguyen wrote: > On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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