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. And about rewriting packed-refs every time, I don't think that's a big problem for "normal" repos. linux-2.6 index file is 4MB(*) and it's rewritten on nearly every worktree-related operation and nobody complains (out loud anyway). Assuming an average ref takes 100 bytes, that's about 41k refs. (*) it's 3MB with index-v4 but I don't think v4 is popular -- Duy -- 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