Re: [RFC] Zit: the git-based single file content tracker

On Fri, 24 Oct 2008, Junio C Hamano wrote:

Jakub Narebski [off-list ref] writes:

quoted

"Giuseppe Bilotta" [off-list ref] writes:

quoted

On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren [off-list ref] wrote:

quoted

quoted

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