All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Lee Hopkins <leerhop@gmail.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: Branch Name Case Sensitivity
Date: Thu, 27 Feb 2014 22:00:43 +0100	[thread overview]
Message-ID: <530FA77B.2030707@alum.mit.edu> (raw)
In-Reply-To: <CAJHY66H2M2aQvQ8MLN7XB4uYiFohRfhhsXhd56hwDR5qMGi6Tg@mail.gmail.com>

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@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2014-02-27 21:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 21:06 Branch Name Case Sensitivity Lee Hopkins
2014-02-27 19:50 ` Junio C Hamano
2014-02-27 20:32   ` Torsten Bögershausen
2014-02-27 20:37     ` Lee Hopkins
2014-02-27 21:00       ` Michael Haggerty [this message]
2014-02-27 22:24     ` Karsten Blees
2014-02-27 23:38       ` Lee Hopkins
2014-02-28  6:41         ` Johannes Sixt
2014-02-28 13:56           ` Karsten Blees
2014-02-28 14:10             ` Lee Hopkins
2014-02-28 18:58             ` Junio C Hamano
2014-02-28 23:22               ` Duy Nguyen
2014-02-28 23:28                 ` Junio C Hamano
2014-03-01  2:42                   ` Lee Hopkins
2014-03-01  6:54                     ` Torsten Bögershausen
2014-03-01 19:38                       ` Lee Hopkins
2014-03-03 10:03                       ` Karsten Blees
2014-03-03 14:21                         ` Lee Hopkins
2014-03-03 17:51                     ` Junio C Hamano
2014-03-04 13:23                       ` Karsten Blees
2014-03-04 20:37                         ` Torsten Bögershausen
2014-03-05 14:02                           ` Lee Hopkins
2014-02-28  9:13         ` Michael Haggerty
2014-02-28 14:31           ` Duy Nguyen
2014-02-28 14:45             ` Michael Haggerty
2014-02-28  9:11       ` Stephen Leake
2014-02-28  9:49         ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530FA77B.2030707@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leerhop@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.