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

From: Junio C Hamano <[email-masked]>
Date: Fri, 24 Oct 2008 11:28:13 -0700

Jakub Narebski <[email-masked]> writes:

> "Giuseppe Bilotta" <[email-masked]> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <[email-masked]> 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.