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

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

[Giuseppe Bilotta]

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

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

[Felipe Oliveira Carvalho]

It sounds interesting. I have some single files that I would like to track
using git, zit seems to be a good solution.

--
Felipe

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

[Nguyen Thai Ngoc Duy]

On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>  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.

Why not use one .zit repo and track each file on each own branch?.
-- 
Duy

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

[Johannes Sixt]

Giuseppe Bilotta schrieb:
> 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.

git breaks hard links, mind you! (Just in case you check out older
versions and you wonder why your "real" file is not updated).

But there's a recent patch by Dscho floating around that takes care of the
hard link case.

-- Hannes

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

[Giuseppe Bilotta]

On Thu, Oct 23, 2008 at 3:03 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Giuseppe Bilotta schrieb:
>> 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.
>
> git breaks hard links, mind you! (Just in case you check out older
> versions and you wonder why your "real" file is not updated).
>
> But there's a recent patch by Dscho floating around that takes care of the
> hard link case.

I feared that the hardlink choice was not the best one. I would
definitely prefer finding a solution that didn't depend on hardlinks:
not only there would be no worry about breaking them, it'd also be
more portable.

-- 
Giuseppe "Oblomov" Bilotta

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

[Giuseppe Bilotta]

On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>>  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.
>
> Why not use one .zit repo and track each file on each own branch?.

So your proposal is to have a single .zit repo which is actually a git
repo and where each additional tracked file becomes its own branch,
and zit would take care of switching from branch to branch when zit
commands are called?

I think this solution would have a number of problems, apart from
being generally quite messy. First of all, moving a file and its
history somewhere else means toying around with the history of a much
wider repo, whereas the current approach would mean just moving the
.zit.file dir together with the file (modulo hardlinks). Non-linear
histories for a single file would be more complex to handle, too. And
publishing just the history of one file would be damn complex.


-- 
Giuseppe "Oblomov" Bilotta

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

[Nguyen Thai Ngoc Duy]

On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>  > On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>  >>  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.
>  >
>  > Why not use one .zit repo and track each file on each own branch?.
>
>
> So your proposal is to have a single .zit repo which is actually a git
>  repo and where each additional tracked file becomes its own branch,
>  and zit would take care of switching from branch to branch when zit
>  commands are called?

I don't know if switching is necessary. With one file per pranch, the
index is even not necessary.

>  I think this solution would have a number of problems, apart from
>  being generally quite messy. First of all, moving a file and its
>  history somewhere else means toying around with the history of a much
>  wider repo, whereas the current approach would mean just moving the
>  .zit.file dir together with the file (modulo hardlinks). Non-linear
>  histories for a single file would be more complex to handle, too. And
>  publishing just the history of one file would be damn complex.

The history should be linear. Git (or zit) repository is just a
container for git branches. Each branch contains only one file. Moving
a file history is equivalent to "git push" + "git branch -D".
Something like this (not tested):

cd dst
git init
cd src
git push dst local-branch:remote-branch
git branch -D local-branch
git gc

>  --
>  Giuseppe "Oblomov" Bilotta
>


-- 
Duy

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

[Giuseppe Bilotta]

On Thu, Oct 23, 2008 at 3:51 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>  > On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>>  >>  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.
>>  >
>>  > Why not use one .zit repo and track each file on each own branch?.
>>
>>
>> So your proposal is to have a single .zit repo which is actually a git
>>  repo and where each additional tracked file becomes its own branch,
>>  and zit would take care of switching from branch to branch when zit
>>  commands are called?
>
> I don't know if switching is necessary. With one file per pranch, the
> index is even not necessary.

[...]

> The history should be linear. Git (or zit) repository is just a
> container for git branches. Each branch contains only one file. Moving
> a file history is equivalent to "git push" + "git branch -D".
> Something like this (not tested):
>
> cd dst
> git init
> cd src
> git push dst local-branch:remote-branch
> git branch -D local-branch
> git gc

Looks a little too clumsy for my taste. Also, I don't like the idea of
having to enforce linear history for files, or getting rid of the
index. I would like zit to be as lightweight a wrapper for git as
possible, retaining the whole functionality.





-- 
Giuseppe "Oblomov" Bilotta

[RFC] Zit (v2): the git-based single file content tracker

[Giuseppe Bilotta]

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.

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.

-- 
Giuseppe "Oblomov" Bilotta

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

[Jean-Luc Herren]

Hi!

Giuseppe Bilotta wrote:
> So today I decided to start hacking at a git-based but file-oriented
> content tracker, which I decided to name Zit.

This sounds great and would seem very useful to manage my ~/bin/
directory which contains a set of unrelated one-file-tools that
evolve over time.  I haven't played with it yet though.

> when you choose to start tracking a file with Zit [...]
> Zit will create a directory .zit.file to hold a git repository

If you have many files you want to track in a single directory
(like ~/bin/), all those additional directories will quickly feel
like clutter.  If you track every file, it will even double the
number of things you see with an "ls -a".

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.

jlh

Re: [RFC] Zit (v2): the git-based single file content tracker

[david]

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.
>
>

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
> Hi!
>
> Giuseppe Bilotta wrote:
>> So today I decided to start hacking at a git-based but file-oriented
>> content tracker, which I decided to name Zit.
>
> This sounds great and would seem very useful to manage my ~/bin/
> directory which contains a set of unrelated one-file-tools that
> evolve over time.  I haven't played with it yet though.

Nice to see I wasn't the only one with such a need 8-)

>> when you choose to start tracking a file with Zit [...]
>> Zit will create a directory .zit.file to hold a git repository
>
> If you have many files you want to track in a single directory
> (like ~/bin/), all those additional directories will quickly feel
> like clutter.  If you track every file, it will even double the
> number of things you see with an "ls -a".

Ah, good point, I hadn't thought about that.

> 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.

-- 
Giuseppe "Oblomov" Bilotta

Re: [RFC] Zit (v2): the git-based single file content tracker

[Giuseppe Bilotta]

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

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

[Jakub Narebski]

"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> 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)

By the way, it would be nice to have VC interface for Emacs for Zit...
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [RFC] Zit (v2): the git-based single file content tracker

[Jakub Narebski]

Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:

> 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.
[...]

Could you add it to Git Wiki page:
  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools

I think that the project is interesting enough to be added there
even if it is still in beta, or even alpha, stage.


P.S. Currently I cannot access git.or.cz for some reason (it is
up for everyone else, and even for me on different remote machine).
-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> 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)

Indeed, there's not particular reason why both solutions shouldn't be
available. I'll think about implementing it this way:

$ zit init

will indicate that we want to track many files, and thus it will
create a .zit directory under which RCS files will be available.

$ zit track somefile

will start tracking somefile by setting up .zit/somefile.git if .zit
is available or .somefile.git otherwise.

The only problem then is priority. When looking for a file's repo, do
we look at .file.git first, or .zit/file.git? How does RCS behave in
this case?

> By the way, it would be nice to have VC interface for Emacs for Zit...

I'm afraid someone else will have to take care of that, since Emacs is
not really something I use.

-- 
Giuseppe "Oblomov" Bilotta

Re: [RFC] Zit (v2): the git-based single file content tracker

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> 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.
> [...]
>
> Could you add it to Git Wiki page:
>  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>
> I think that the project is interesting enough to be added there
> even if it is still in beta, or even alpha, stage.

Ah, good idea. Done, in Version Control Interface layers section

-- 
Giuseppe "Oblomov" Bilotta

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

[Jakub Narebski]

On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> 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)
> 
> Indeed, there's not particular reason why both solutions shouldn't be
> available. [...]

> The only problem then is priority. When looking for a file's repo, do
> we look at .file.git first, or .zit/file.git? How does RCS behave in
> this case?

rcsintro(1) states:

  If you don't want to clutter your working directory with RCS files, create
  a  subdirectory called RCS in your working directory, and move all your RCS
  files there.  RCS commands will look *first* into that directory to find
  needed files.

>> By the way, it would be nice to have VC interface for Emacs for Zit...
> 
> I'm afraid someone else will have to take care of that, since Emacs is
> not really something I use.

I'll try to hack it using contrib/emacs/vc-git.el as a base...

-- 
Jakub Narebski
Poland

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 1:32 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> 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)
>>
>> Indeed, there's not particular reason why both solutions shouldn't be
>> available. [...]
>
>> The only problem then is priority. When looking for a file's repo, do
>> we look at .file.git first, or .zit/file.git? How does RCS behave in
>> this case?
>
> rcsintro(1) states:
>
>  If you don't want to clutter your working directory with RCS files, create
>  a  subdirectory called RCS in your working directory, and move all your RCS
>  files there.  RCS commands will look *first* into that directory to find
>  needed files.

Cool. I pushed changes to this end to git.oblomov.eu/zit --now zit
will look for .zit/file.git first, then for .file.git; if neither is
found, and .zit/ exists, the repo is set to .zit/file.git, otherwise
it's set to .file.git

You can either manually mkdir .zit, or use zit init that does exactly
the same thing.

>>> By the way, it would be nice to have VC interface for Emacs for Zit...
>>
>> I'm afraid someone else will have to take care of that, since Emacs is
>> not really something I use.
>
> I'll try to hack it using contrib/emacs/vc-git.el as a base...

Cool, thanks.

-- 
Giuseppe "Oblomov" Bilotta

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

[Johannes Schindelin]

Hi,

On Thu, 23 Oct 2008, Johannes Sixt wrote:

> Giuseppe Bilotta schrieb:
> > 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.
> 
> git breaks hard links, mind you! (Just in case you check out older 
> versions and you wonder why your "real" file is not updated).
> 
> But there's a recent patch by Dscho floating around that takes care of 
> the hard link case.

Yep, I still want to work on it; it breaks on one of Junio's machines.

Ciao,
Dscho

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 7:44 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 23 Oct 2008, Johannes Sixt wrote:
>
>> Giuseppe Bilotta schrieb:
>> > 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.
>>
>> git breaks hard links, mind you! (Just in case you check out older
>> versions and you wonder why your "real" file is not updated).
>>
>> But there's a recent patch by Dscho floating around that takes care of
>> the hard link case.
>
> Yep, I still want to work on it; it breaks on one of Junio's machines.

Well, it's not needed by Zit anymore, but there was someone else
asking about on the ml recently, too 8-)



-- 
Giuseppe "Oblomov" Bilotta

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> 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.

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

[david]

On Fri, 24 Oct 2008, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
>
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> 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.

the reason to use seperate repos is to ease the work involved if you need 
to move that file (and it's repo) elsewhere.

with the git directory being under .zit, would it be possible to link the 
things that are nessasary togeather?

hmm, looking at this in more detail.

about 44K of diskspace is used by the .sample hook files, so those can be 
removed

the remaining 56K is mostly directories eating up a disk block

find . -ls
200367    4 drwxr-xr-x   7 dlang    users        4096 Oct 24 12:00 .
200368    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./refs
200369    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./refs/heads
200370    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./refs/tags
200371    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./branches
200372    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./hooks
200373    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./info
1798469   4 -rw-r--r--   1 dlang    users         240 Oct 24 12:00 ./info/exclude
1600716   4 -rw-r--r--   1 dlang    users          58 Oct 24 12:00 ./description
200374    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./objects
200375    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./objects/pack
200376    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./objects/info
1600717   4 -rw-r--r--   1 dlang    users          23 Oct 24 12:00 ./HEAD
1600719   4 -rw-r--r--   1 dlang    users          92 Oct 24 12:00 ./config

how many of these are _really_ nessasary?

tags, info, hooks, branches, and description could probably be skipped for 
the common zit case, as long as they can be created as needed.

If git has problems with these not existing, would it make sense to make 
git survive if they are missing and create them if needed?

the objects directory will eat up more space as revisions are checked in 
(and more sub-directories are created), would it make sense to have a 
config option to do a flat objects directory instead of the current 
fan-out?

the other option with objects would be to look into having a common 
objects fan-out directory, but have the pack directory be per file. This 
would allow you to seperate out one files stuff by creating packs for it 
and then grabbing everything in the per-file directory.

thoughts?

David Lang

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

[Giuseppe Bilotta]

I was slowly writing a reply but it seems David beat me to it, so here
goes a couple of additional comments.

On Fri, Oct 24, 2008 at 9:11 PM,  <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>> 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.
>
> the reason to use seperate repos is to ease the work involved if you need to
> move that file (and it's repo) elsewhere.

Precisely. The one-repo-per-file is just the simplest and most
flexible solution. But yes, I have to admit I hadn't looked into disk
usage, and indeed we should try and squeeze this as much as possible.

> with the git directory being under .zit, would it be possible to link the
> things that are nessasary togeather?

I'm not sure about _which_ files could be shared.

> hmm, looking at this in more detail.
>
> about 44K of diskspace is used by the .sample hook files, so those can be
> removed

Exactly. I'm setting up zit to prepare its repos to a more compact
form, and getting rid of hooks and description is the first step.

> the remaining 56K is mostly directories eating up a disk block
>
> find . -ls
> 200367    4 drwxr-xr-x   7 dlang    users        4096 Oct 24 12:00 .
> 200368    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./refs
> 200369    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./refs/heads
> 200370    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./refs/tags
> 200371    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./branches
> 200372    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./hooks
> 200373    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./info
> 1798469   4 -rw-r--r--   1 dlang    users         240 Oct 24 12:00
> ./info/exclude
> 1600716   4 -rw-r--r--   1 dlang    users          58 Oct 24 12:00
> ./description
> 200374    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./objects
> 200375    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./objects/pack
> 200376    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
> ./objects/info
> 1600717   4 -rw-r--r--   1 dlang    users          23 Oct 24 12:00 ./HEAD
> 1600719   4 -rw-r--r--   1 dlang    users          92 Oct 24 12:00 ./config
>
> how many of these are _really_ nessasary?

For starters, I'm wondering if setting core.preferSymlinkRefs would be
useful here. Does it break sometihng?

> tags, info, hooks, branches, and description could probably be skipped for
> the common zit case, as long as they can be created as needed.

It seems that tags, hooks, branches and description can be done with.

info contains exclude which is rather essential, and this is something
that could be shared across repositories. Also, we could spare a block
by removing info, moving exclude to the .git dir and setting
core.excludesfile appropriately

> the objects directory will eat up more space as revisions are checked in
> (and more sub-directories are created), would it make sense to have a config
> option to do a flat objects directory instead of the current fan-out?

This is probably the biggest remaining spacewaste. Typical zit usage
will generate a rather small number of objects, so flattening the
object store for the repo wouldn't be a bad idea. Is that possible?

-- 
Giuseppe "Oblomov" Bilotta

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

[david]

On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:

> I was slowly writing a reply but it seems David beat me to it, so here
> goes a couple of additional comments.
>
> On Fri, Oct 24, 2008 at 9:11 PM,  <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>>> 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.
>>
>> the reason to use seperate repos is to ease the work involved if you need to
>> move that file (and it's repo) elsewhere.
>
> Precisely. The one-repo-per-file is just the simplest and most
> flexible solution. But yes, I have to admit I hadn't looked into disk
> usage, and indeed we should try and squeeze this as much as possible.
>
>> with the git directory being under .zit, would it be possible to link the
>> things that are nessasary togeather?
>
> I'm not sure about _which_ files could be shared.
>
>> hmm, looking at this in more detail.
>>
>> about 44K of diskspace is used by the .sample hook files, so those can be
>> removed
>
> Exactly. I'm setting up zit to prepare its repos to a more compact
> form, and getting rid of hooks and description is the first step.
>
>> the remaining 56K is mostly directories eating up a disk block
>>
>> find . -ls
>> 200367    4 drwxr-xr-x   7 dlang    users        4096 Oct 24 12:00 .
>> 200368    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./refs
>> 200369    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
>> ./refs/heads
>> 200370    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
>> ./refs/tags
>> 200371    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
>> ./branches
>> 200372    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./hooks
>> 200373    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00 ./info
>> 1798469   4 -rw-r--r--   1 dlang    users         240 Oct 24 12:00
>> ./info/exclude
>> 1600716   4 -rw-r--r--   1 dlang    users          58 Oct 24 12:00
>> ./description
>> 200374    4 drwxr-xr-x   4 dlang    users        4096 Oct 24 12:00 ./objects
>> 200375    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
>> ./objects/pack
>> 200376    4 drwxr-xr-x   2 dlang    users        4096 Oct 24 12:00
>> ./objects/info
>> 1600717   4 -rw-r--r--   1 dlang    users          23 Oct 24 12:00 ./HEAD
>> 1600719   4 -rw-r--r--   1 dlang    users          92 Oct 24 12:00 ./config
>>
>> how many of these are _really_ nessasary?
>
> For starters, I'm wondering if setting core.preferSymlinkRefs would be
> useful here. Does it break sometihng?
>
>> tags, info, hooks, branches, and description could probably be skipped for
>> the common zit case, as long as they can be created as needed.
>
> It seems that tags, hooks, branches and description can be done with.

do you mean 'can be done away with'?

> info contains exclude which is rather essential,

is it? by default everything in this file is commented out. And with you 
only adding files explicitly why would it ever need to excluded anything?

David Lang

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 9:46 PM,  <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>
>> It seems that tags, hooks, branches and description can be done with.
>
> do you mean 'can be done away with'?

Ahem. Yes. I've got a patch ready for zit that gets rid of them.

(A smarter way would be to create a template, but I'm not smart.)

>> info contains exclude which is rather essential,
>
> is it? by default everything in this file is commented out. And with you
> only adding files explicitly why would it ever need to excluded anything?

Zit does
 		echo "*" > $GIT_DIR/info/exclude
and yes it sucks to use a whole block for a file that only contains
one character. Suggestions welcome.

The reason why we want the exclude is that when you do zit status
somefile you don't want every other file in the directory to come up
as 'not tracked'.

-- 
Giuseppe "Oblomov" Bilotta

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

[david]

On Fri, 24 Oct 2008, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
>
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> 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.

I just had what's probably a silly thought.

how close is a zit setup to a subproject setup?

David Lang

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

[david]

On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:

> On Fri, Oct 24, 2008 at 9:46 PM,  <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>>
>>> It seems that tags, hooks, branches and description can be done with.
>>
>> do you mean 'can be done away with'?
>
> Ahem. Yes. I've got a patch ready for zit that gets rid of them.
>
> (A smarter way would be to create a template, but I'm not smart.)
>
>>> info contains exclude which is rather essential,
>>
>> is it? by default everything in this file is commented out. And with you
>> only adding files explicitly why would it ever need to excluded anything?
>
> Zit does
> 		echo "*" > $GIT_DIR/info/exclude
> and yes it sucks to use a whole block for a file that only contains
> one character. Suggestions welcome.

can this be configured in the config file?

> The reason why we want the exclude is that when you do zit status
> somefile you don't want every other file in the directory to come up
> as 'not tracked'.

good point.

David Lang

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 9:53 PM,  <david@lang.hm> wrote:
> I just had what's probably a silly thought.
>
> how close is a zit setup to a subproject setup?

Honestly, I haven't the slightest idea how they work. My
understanding, which could be completely wrong, is that they are
full-fledged git repositories, and that additional metadata at the top
level takes care of understanding what ref is needed for each toplevel
project. If this is true, using them wouldn't simplify zit, but rather
make it more complex (and space intensive).

-- 
Giuseppe "Oblomov" Bilotta

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 9:54 PM,  <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> Zit does
>>                echo "*" > $GIT_DIR/info/exclude
>> and yes it sucks to use a whole block for a file that only contains
>> one character. Suggestions welcome.
>
> can this be configured in the config file?

Yes, the file pointed at by the config key core.excludesfile is read
too, so we could have it point at $GIT_DIR/zitexclude, which would
allow us to spare a block. The most space saving would be achieved by
a core.excludepattern or similar key, which would allow us to get rid
of the exclude file altogether.

-- 
Giuseppe "Oblomov" Bilotta

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

[Jakub Narebski]

On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 9:54 PM,  <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>> Zit does
>>>                echo "*" > $GIT_DIR/info/exclude
>>> and yes it sucks to use a whole block for a file that only contains
>>> one character. Suggestions welcome.
>>
>> can this be configured in the config file?
> 
> Yes, the file pointed at by the config key core.excludesfile is read
> too, so we could have it point at $GIT_DIR/zitexclude, which would
> allow us to spare a block. The most space saving would be achieved by
> a core.excludepattern or similar key, which would allow us to get rid
> of the exclude file altogether.

Well, with all zit repositories in '.zit/' directory (similar to RCS/)
you could have point core.excludesfile to _common_ '.zit/excludes';
the pattern doesn't change from zit repository to zit repository?

You could even use per-user ~/.zitignore (I'm not sure if git expands 
'~' in paths; there was some patch for it, but was it accepted?) or 
system-wide /usr/lib/zitignore or /usr/libexec/zitignore file.
-- 
Jakub Narebski
Poland

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

[Giuseppe Bilotta]

On Fri, Oct 24, 2008 at 10:30 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Well, with all zit repositories in '.zit/' directory (similar to RCS/)
> you could have point core.excludesfile to _common_ '.zit/excludes';
> the pattern doesn't change from zit repository to zit repository?
>
> You could even use per-user ~/.zitignore (I'm not sure if git expands
> '~' in paths; there was some patch for it, but was it accepted?) or
> system-wide /usr/lib/zitignore or /usr/libexec/zitignore file.

System-wide means maximum space save, but it require system
administration to install Zit, and considering that one of the things
I love of Zit now is its being self contained, I would rather not
depend on anything system-wide anyway.

The user .zitignore file is probably the best approach: we can create
it ourselves (usually), and even if Git doesn't expand the pathname
itself, we can just use an absolute path. I'll go that way.

-- 
Giuseppe "Oblomov" Bilotta

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

[Jakub Narebski]

On Sat, 25 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 10:30 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Well, with all zit repositories in '.zit/' directory (similar to RCS/)
> > you could have point core.excludesfile to _common_ '.zit/excludes';
> > the pattern doesn't change from zit repository to zit repository?
> >
> > You could even use per-user ~/.zitignore (I'm not sure if git expands
> > '~' in paths; there was some patch for it, but was it accepted?) [...]
[...]
 
> The user .zitignore file is probably the best approach: we can create
> it ourselves (usually), and even if Git doesn't expand the pathname
> itself, we can just use an absolute path. I'll go that way.

First, absolute path to ~/.zitignore is a bit fragile: what if layout
of home directories for users change, for example because of increasing
number of users some fan-out is required (/home/nick -> /home/2/nick)?
Second, ~/.zitignore looks like something that user can change; if
you install zit, it can install libexec/zitignore somewhere... or just
use ./zit/excludes (with 'do not edit' comment perhaps...).

-- 
Jakub Narebski
Poland

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

[Giuseppe Bilotta]

On Sat, Oct 25, 2008 at 11:10 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 25 Oct 2008, Giuseppe Bilotta wrote:
>
>> The user .zitignore file is probably the best approach: we can create
>> it ourselves (usually), and even if Git doesn't expand the pathname
>> itself, we can just use an absolute path. I'll go that way.
>
> First, absolute path to ~/.zitignore is a bit fragile: what if layout
> of home directories for users change, for example because of increasing
> number of users some fan-out is required (/home/nick -> /home/2/nick)?
> Second, ~/.zitignore looks like something that user can change; if
> you install zit, it can install libexec/zitignore somewhere... or just
> use ./zit/excludes (with 'do not edit' comment perhaps...).

(Actually, I just found another interesting thing about the config, in
that it stores the path to the work tree. This is not a problem,
though, because zit_setup() sets GIT_WORK_TREE.)

As I said, I don't like depending on stuff that needs to be installed.
For example, what about user (non-system) installs? the libexec (or
whatever) solution would have the same problem as the ~/.zitignore
solution, with the moving $HOME.

I guess this leaves the .zit/ solution as the most robust one,
although it's not the most space-effective, especially if you have
many directories, each with a single tracked file. On the plus side,
going for the .zit/ solution and dropping support for .somefile.git/
means some significant code semplification.

-- 
Giuseppe "Oblomov" Bilotta

Re: [RFC] Zit (v2): the git-based single file content tracker

[Jakub Narebski]

"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>>> 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.
>> [...]
>>
>> Could you add it to Git Wiki page:
>>  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>>
>> I think that the project is interesting enough to be added there
>> even if it is still in beta, or even alpha, stage.
> 
> Ah, good idea. Done, in Version Control Interface layers section

Thanks.

I have added link to repositoy, as you didn't configure your gitweb to
display those URL links (see gitweb/README and gitweb/INSTALL).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [RFC] Zit (v2): the git-based single file content tracker

[Giuseppe Bilotta]

On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> Ah, good idea. Done, in Version Control Interface layers section
>
> Thanks.
>
> I have added link to repositoy, as you didn't configure your gitweb to
> display those URL links (see gitweb/README and gitweb/INSTALL).

Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
computed automatically? Judging by the docs, it seems that I have to
set it manually for each project, like the description.


-- 
Giuseppe "Oblomov" Bilotta

Re: [RFC] Zit (v2): the git-based single file content tracker

[Jakub Narebski]

Giuseppe Bilotta wrote:
> On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>>
>>> Ah, good idea. Done, in Version Control Interface layers section
>>
>> Thanks.
>>
>> I have added link to repositoy, as you didn't configure your gitweb to
>> display those URL links (see gitweb/README and gitweb/INSTALL).
> 
> Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
> computed automatically? Judging by the docs, it seems that I have to
> set it manually for each project, like the description.

gitweb/README:

  How to configure gitweb for your local system
  ---------------------------------------------
  [...]
   * GITWEB_BASE_URL
     Git base URLs used for URL to where fetch project from, i.e. full
     URL is "$git_base_url/$project".  Shown on projects summary page.
     Repository URL for project can be also configured per repository; this
     takes precedence over URLs composed from base URL and a project name.
     Note that you can setup multiple base URLs (for example one for
     git:// protocol access, another for http:// access) from the gitweb
     config file.  [No default]

  [...]
  Runtime gitweb configuration
  ----------------------------
  [...]
  Gitweb config file variables
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  [...]
   * @git_base_url_list
     List of git base URLs used for URL to where fetch project from, shown
     in project summary page.  Full URL is "$git_base_url/$project".
     You can setup multiple base URLs (for example one for  git:// protocol
     access, and one for http:// "dumb" protocol access).  Note that per
     repository configuration in 'cloneurl' file, or as values of gitweb.url
     project config.

Ooops, there seems to be a type in above...

  Per-repository gitweb configuration
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  [...]
   * cloneurl (or multiple-valued gitweb.url)
     File with repository URL (used for clone and fetch), one per line.
     Displayed in the project summary page. You can use multiple-valued
     gitweb.url repository configuration variable for that, but the file
     takes precedence.

-- 
Jakub Narebski
Poland

Re: [RFC] Zit (v2): the git-based single file content tracker

[Giuseppe Bilotta]

On Sun, Oct 26, 2008 at 11:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>  Gitweb config file variables
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  [...]
>   * @git_base_url_list
>     List of git base URLs used for URL to where fetch project from, shown
>     in project summary page.  Full URL is "$git_base_url/$project".
>     You can setup multiple base URLs (for example one for  git:// protocol
>     access, and one for http:// "dumb" protocol access).  Note that per
>     repository configuration in 'cloneurl' file, or as values of gitweb.url
>     project config.

Doh, thanks, I had totally overlooked it. Done 8-)

-- 
Giuseppe "Oblomov" Bilotta