Jakub Narebski <jnareb@xxxxxxxxx> writes: > "Giuseppe Bilotta" <giuseppe.bilotta@xxxxxxxxx> writes: >> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
