From: david@lang.hm
To: Junio C Hamano <gitster@pobox.com>
Cc: Jakub Narebski <jnareb@gmail.com>,
Giuseppe Bilotta <giuseppe.bilotta@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 12:11:35 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm> (raw)
In-Reply-To: <7vabct3l1e.fsf@gitster.siamese.dyndns.org>
On Fri, 24 Oct 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>>
>>>> If you decide against a shared repository, maybe you want to
>>>> consider to not use ".zit.file/", but ".zit/file/" as the
>>>> repository? This would reduce the clutter to a single directory,
>>>> just like with ".git". And moving files around wouldn't be that
>>>> much complicated.
>>>
>>> Right. I'll give that a shot.
>>
>> By the way RCS which I use for version control of single files use
>> both approaches: it can store 'file,v' alongside 'file' (just like
>> your '.zit.file/' or '.file.git/'), but it can also store files on
>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>> '.zit/file.git/' solution)
>
> I am not opposed to the wish to track a single file (but I have to say I
> am not personally in need for such a feature), but I have to wonder from
> the technical point of view if one-repo-per-file is the right approach.
>
> 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.
with the git directory being under .zit, would it be possible to link the
things that are nessasary togeather?
hmm, looking at this in more detail.
about 44K of diskspace is used by the .sample hook files, so those can be
removed
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?
tags, info, hooks, branches, and description could probably be skipped for
the common zit case, as long as they can be created as needed.
If git has problems with these not existing, would it make sense to make
git survive if they are missing and create them if needed?
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?
the other option with objects would be to look into having a common
objects fan-out directory, but have the pack directory be per file. This
would allow you to seperate out one files stuff by creating packs for it
and then grabbing everything in the per-file directory.
thoughts?
David Lang
next prev parent reply other threads:[~2008-10-24 19:12 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 [this message]
2008-10-24 19:42 ` Giuseppe Bilotta
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=alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm \
--to=david@lang.hm \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=giuseppe.bilotta@gmail.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).