Hello all, one of the common remarks done about git is that since it tracks tree contents, it's not the best-suited tool to track a bunch of independent files which happen to be in the same directory. I've found myself in the situation of wanting to track my changes done to one or more 'single' files in a directory (e.g. $HOME), and deciding to use antiquate, clumsy, slow and inefficient but file-based RCS (yes, you read that right) over git. In other situations (e.g. for my UserJS folder) I ended up using git, but not liking the idea of having things such as tags referring to all of my UserJS projects instead of the single file they were inteded for, or having to put 'filename: ' at the beginning of commit messages just because the history was shared. So today I decided to start hacking at a git-based but file-oriented content tracker, which I decided to name Zit. The principle is extremely simple: when you choose to start tracking a file with Zit, zit track file Zit will create a directory .zit.file to hold a git repository tracking the single file .zit.file/file, which is just a hard link to file. The reason for using .zit.file as a non-bare repository rather than just a GIT_DIR is that it allows things such as 'git status' to ignore everything else. A possible alternative could have been to use .zit.file as the GIT_DIR and create an all-encopassing .zit.file/info/exclude, but the general idea of having this kind of detached GIT_DIR felt less robust (or maybe I just forgot some export). I also don't like the idea of the hardlink, first of all because of portability problems, and secondly because of the way too many possibility that the hardlink broke somewhere along the way. For example, I haven't tested any fancy git commands on my sample zit implementation, and I'm not sure checking out some older version would actually work. If anybody is intered in trying out my quick hack for the idea, there's a git repository for Zit at git://git.oblomov.eu/zit --beware that nothing past the most elementary uses (i.e. diff, status, log, commit) has been tested yet. Many commands are bound to fail due to the braindead way commands are delegated to git. Suggestions on the best way to approach the many limits of the implementation are more than welcome. -- Giuseppe "Oblomov" Bilotta -- 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
