git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: "Lee Hopkins" <leerhop@gmail.com>,
	"Karsten Blees" <karsten.blees@gmail.com>,
	"Torsten Bögershausen" <tboegi@web.de>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: Branch Name Case Sensitivity
Date: Fri, 28 Feb 2014 21:31:29 +0700	[thread overview]
Message-ID: <CACsJy8B7fFBJ5ZbJDjGj4G6mx1byitC7BU4oJ3C0zq7cuv4fvA@mail.gmail.com> (raw)
In-Reply-To: <53105343.2040703@alum.mit.edu>

On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty <mhagger@alum.mit.edu> 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

  reply	other threads:[~2014-02-28 14:32 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
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 [this message]
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=CACsJy8B7fFBJ5ZbJDjGj4G6mx1byitC7BU4oJ3C0zq7cuv4fvA@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karsten.blees@gmail.com \
    --cc=leerhop@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).