On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:
I decided to give the simpler GIT_DIR approach another go.
The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
.file.git/ to track file's history. .file.git/info/excludes is
initialized to the very strong '*' pattern to ensure that things such
as git status etc only consider the actually tracked file.
The obvious advantage over the previous implementation is that we
don't rely on fragile and non-portable hardlinks. The disadvantage
is that something really bad can happen if a command fails to obey
GIT_DIR or GIT_WORK_TREE correctly.
this is a very interesting approach.
the thought that hit me as I finidhed reading this thread is that we
are very close to having the full continum of file/repository combinations
1. everything in the dir is part of one repository (the normal git case)
2. some of all of the individual files in a dir is it's own repository
(the zit case)
3. the in-between case where you can have multiple repositories that can
have multiple files in them.
how hard would it be to extend zit to support case #3?
offhand I can see it complicating the task of figuing out which repository
to use for a file, but what else?
David Lang
Command delegation is made a little smarter:
zit somecommand file [args...]
gets delegated to
git somecommand [args...]
with GIT_DIR=.file.git and GIT_WORK_TREE="`pwd`", which works
surprisingly well. To prevent stupid expressions such as zit add file
file or zit commit file file, add and commit put the filename back at
the end of the parameter list.
Commands that seem to work correctly so far are init, add, log,
status, diff, remote, push, pull, and even rebase -i.
Commands that definitely need some work are rm (should it just remove
the .file.git/ dir?) and mv (hairy: we would need to rename .file.git
to .newname.git too, but rollbacks are likely to break things).
The only new command introduced by zit is zit list, which lists all
zit-tracked files in the current directory, currently in a very
braindead way (e.g. I'd like it to display the proper status, such as
C M or whatever; suggestions welcome).
On the TODO list is also some smart way to guess which file we're
talking about when no file is specified. Basically, the idea is to
check if there's only one tracked file, or only one changed tracked
file, and allow a missing file option in that case.
As usual, comments suggestions and critiques welcome.
--
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
