On 02/28/2014 03:31 PM, Duy Nguyen wrote:
> On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty <mhag...@alum.mit.edu>
>> 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
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html