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
--
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