On 02/27/2014 09:37 PM, Lee Hopkins wrote:
>> 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 Haggerty
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

Reply via email to