Re: [RFC] Zit: the git-based single file content tracker
- From
- david@lang.hm <david@lang.hm>
- Date
- Oct 24, 2008, 19:11 UTC
- Message-ID
- <alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm>
- In-Reply-To
- <7vabct3l1e.fsf@gitster.siamese.dyndns.org>
On Fri, 24 Oct 2008, Junio C Hamano wrote:
Show 28 quoted lines
> 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