git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>
To: david@lang.hm
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Jakub Narebski" <jnareb@gmail.com>,
	"Jean-Luc Herren" <jlh@gmx.ch>,
	git@vger.kernel.org
Subject: Re: [RFC] Zit: the git-based single file content tracker
Date: Fri, 24 Oct 2008 21:42:09 +0200	[thread overview]
Message-ID: <cb7bb73a0810241242y7467f6fexcca4b7cd768e7992@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm>

I was slowly writing a reply but it seems David beat me to it, so here
goes a couple of additional comments.

On Fri, Oct 24, 2008 at 9:11 PM,  <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>> Running "git init" in an empty directory consumes about 100k of diskspace
>> on the machine I am typing this on, and you should be able to share most
>> of them (except one 41-byte file that is the branch tip ref) when you
>> track many files inside a single directory by using a single repository,
>> one branch per file (or "one set of branches per file") model.
>
> the reason to use seperate repos is to ease the work involved if you need to
> move that file (and it's repo) elsewhere.

Precisely. The one-repo-per-file is just the simplest and most
flexible solution. But yes, I have to admit I hadn't looked into disk
usage, and indeed we should try and squeeze this as much as possible.

> with the git directory being under .zit, would it be possible to link the
> things that are nessasary togeather?

I'm not sure about _which_ files could be shared.

> hmm, looking at this in more detail.
>
> about 44K of diskspace is used by the .sample hook files, so those can be
> removed

Exactly. I'm setting up zit to prepare its repos to a more compact
form, and getting rid of hooks and description is the first step.

> the remaining 56K is mostly directories eating up a disk block
>
> find . -ls
> 200367    4 drwxr-xr-x   7 dlang    users        4096 Oct 24 12:00 .
> 200368    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./refs
> 200369    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./refs/heads
> 200370    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./refs/tags
> 200371    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./branches
> 200372    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./hooks
> 200373    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./info
> 1798469   4 -rw-r--r--   1 dlang    users         240 Oct 24 12:00
> ./info/exclude
> 1600716   4 -rw-r--r--   1 dlang    users          58 Oct 24 12:00
> ./description
> 200374    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./objects
> 200375    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./objects/pack
> 200376    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./objects/info
> 1600717   4 -rw-r--r--   1 dlang    users          23 Oct 24 12:00 ./HEAD
> 1600719   4 -rw-r--r--   1 dlang    users          92 Oct 24 12:00 ./config
>
> how many of these are _really_ nessasary?

For starters, I'm wondering if setting core.preferSymlinkRefs would be
useful here. Does it break sometihng?

> tags, info, hooks, branches, and description could probably be skipped for
> the common zit case, as long as they can be created as needed.

It seems that tags, hooks, branches and description can be done with.

info contains exclude which is rather essential, and this is something
that could be shared across repositories. Also, we could spare a block
by removing info, moving exclude to the .git dir and setting
core.excludesfile appropriately

> the objects directory will eat up more space as revisions are checked in
> (and more sub-directories are created), would it make sense to have a config
> option to do a flat objects directory instead of the current fan-out?

This is probably the biggest remaining spacewaste. Typical zit usage
will generate a rather small number of objects, so flattening the
object store for the repo wouldn't be a bad idea. Is that possible?

-- 
Giuseppe "Oblomov" Bilotta

  reply	other threads:[~2008-10-24 19:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23  1:29 [RFC] Zit: the git-based single file content tracker Giuseppe Bilotta
2008-10-23 12:33 ` Felipe Oliveira Carvalho
2008-10-23 12:50 ` Nguyen Thai Ngoc Duy
2008-10-23 13:33   ` Giuseppe Bilotta
2008-10-23 13:51     ` Nguyen Thai Ngoc Duy
2008-10-23 14:21       ` Giuseppe Bilotta
2008-10-23 13:03 ` Johannes Sixt
2008-10-23 13:28   ` Giuseppe Bilotta
2008-10-24 17:44   ` Johannes Schindelin
2008-10-24 17:48     ` Giuseppe Bilotta
2008-10-23 17:22 ` [RFC] Zit (v2): " Giuseppe Bilotta
2008-10-24  6:21   ` david
2008-10-24  7:14     ` Giuseppe Bilotta
2008-10-24 10:43   ` Jakub Narebski
2008-10-24 11:01     ` Giuseppe Bilotta
2008-10-26 15:20       ` Jakub Narebski
2008-10-26 21:18         ` Giuseppe Bilotta
2008-10-26 22:04           ` Jakub Narebski
2008-10-26 22:16             ` Giuseppe Bilotta
2008-10-23 23:23 ` [RFC] Zit: " Jean-Luc Herren
2008-10-24  6:55   ` Giuseppe Bilotta
2008-10-24 10:31     ` Jakub Narebski
2008-10-24 10:52       ` Giuseppe Bilotta
2008-10-24 11:32         ` Jakub Narebski
2008-10-24 12:15           ` Giuseppe Bilotta
2008-10-24 18:28       ` Junio C Hamano
2008-10-24 19:11         ` david
2008-10-24 19:42           ` Giuseppe Bilotta [this message]
2008-10-24 19:46             ` david
2008-10-24 19:51               ` Giuseppe Bilotta
2008-10-24 19:54                 ` david
2008-10-24 20:13                   ` Giuseppe Bilotta
2008-10-24 20:30                     ` Jakub Narebski
2008-10-25  7:48                       ` Giuseppe Bilotta
2008-10-25  9:10                         ` Jakub Narebski
2008-10-25 10:30                           ` Giuseppe Bilotta
2008-10-24 19:53         ` david
2008-10-24 20:06           ` Giuseppe Bilotta

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=cb7bb73a0810241242y7467f6fexcca4b7cd768e7992@mail.gmail.com \
    --to=giuseppe.bilotta@gmail.com \
    --cc=david@lang.hm \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jlh@gmx.ch \
    --cc=jnareb@gmail.com \
    /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).