From: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>
To: david@lang.hm
Cc: git@vger.kernel.org
Subject: Re: [RFC] Zit (v2): the git-based single file content tracker
Date: Fri, 24 Oct 2008 09:14:26 +0200 [thread overview]
Message-ID: <cb7bb73a0810240014o2209194dodc4a6fe3b754b04f@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0810232314490.20238@asgard.lang.hm>
On Fri, Oct 24, 2008 at 8:21 AM, <david@lang.hm> wrote:
> 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 figuring out which repository
> to use for a file, but what else?
I haven't tried this yet, but I think it should be possible without
much problems. The important thing to keep in mind is that the second
parameter to zit (for all commands but zit init) 'only' identifies the
repository, and the filename parameter is NOT passed to git. The only
exceptions are zit add and git commit, and I'm having second thoughts
on add. Anyway, you can always use the 'raw' version of a command to
guarantee that only GIT_DIR and GIT_WORK_TREE are set, thus:
$ zit rawadd somefile -f someotherfile
will force-add someotherfile to somefile's repo. (Force adding is
required because of the blanket exclude.) Of course, it would be
interesting adding to zit the capability to do
$ zit diff someotherfile
to make it guess that it should use somefile's repo. This is possible
with some symlinks for the git repos, probably.
I'll have a look into it.
--
Giuseppe "Oblomov" Bilotta
next prev parent reply other threads:[~2008-10-24 7:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 1:29 [RFC] Zit: the git-based single file content tracker Giuseppe Bilotta
2008-10-23 12:33 ` Felipe Oliveira Carvalho
2008-10-23 12:50 ` Nguyen Thai Ngoc Duy
2008-10-23 13:33 ` Giuseppe Bilotta
2008-10-23 13:51 ` Nguyen Thai Ngoc Duy
2008-10-23 14:21 ` Giuseppe Bilotta
2008-10-23 13:03 ` Johannes Sixt
2008-10-23 13:28 ` Giuseppe Bilotta
2008-10-24 17:44 ` Johannes Schindelin
2008-10-24 17:48 ` Giuseppe Bilotta
2008-10-23 17:22 ` [RFC] Zit (v2): " Giuseppe Bilotta
2008-10-24 6:21 ` david
2008-10-24 7:14 ` Giuseppe Bilotta [this message]
2008-10-24 10:43 ` Jakub Narebski
2008-10-24 11:01 ` Giuseppe Bilotta
2008-10-26 15:20 ` Jakub Narebski
2008-10-26 21:18 ` Giuseppe Bilotta
2008-10-26 22:04 ` Jakub Narebski
2008-10-26 22:16 ` Giuseppe Bilotta
2008-10-23 23:23 ` [RFC] Zit: " Jean-Luc Herren
2008-10-24 6:55 ` Giuseppe Bilotta
2008-10-24 10:31 ` Jakub Narebski
2008-10-24 10:52 ` Giuseppe Bilotta
2008-10-24 11:32 ` Jakub Narebski
2008-10-24 12:15 ` Giuseppe Bilotta
2008-10-24 18:28 ` Junio C Hamano
2008-10-24 19:11 ` david
2008-10-24 19:42 ` Giuseppe Bilotta
2008-10-24 19:46 ` david
2008-10-24 19:51 ` Giuseppe Bilotta
2008-10-24 19:54 ` david
2008-10-24 20:13 ` Giuseppe Bilotta
2008-10-24 20:30 ` Jakub Narebski
2008-10-25 7:48 ` Giuseppe Bilotta
2008-10-25 9:10 ` Jakub Narebski
2008-10-25 10:30 ` Giuseppe Bilotta
2008-10-24 19:53 ` david
2008-10-24 20:06 ` Giuseppe Bilotta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb7bb73a0810240014o2209194dodc4a6fe3b754b04f@mail.gmail.com \
--to=giuseppe.bilotta@gmail.com \
--cc=david@lang.hm \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).