From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:31
Jakub Narebski [off-list ref] writes:
"Giuseppe Bilotta" [off-list ref] writes:
quoted
On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren [off-list ref] wrote:
quoted
quoted
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.
On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren [off-list ref] wrote:
quoted
quoted
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
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:31
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, [off-list ref] wrote:
On Fri, 24 Oct 2008, Junio C Hamano wrote:
quoted
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
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, [off-list ref] wrote:
quoted
On Fri, 24 Oct 2008, Junio C Hamano wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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?
quoted
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
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:31
On Fri, Oct 24, 2008 at 9:46 PM, [off-list ref] wrote:
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
quoted
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.)
quoted
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
On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren [off-list ref] wrote:
quoted
quoted
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
On Fri, Oct 24, 2008 at 9:46 PM, [off-list ref] wrote:
quoted
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
quoted
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.)
quoted
quoted
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'.
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:31
On Fri, Oct 24, 2008 at 9:53 PM, [off-list ref] 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
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:31
On Fri, Oct 24, 2008 at 9:54 PM, [off-list ref] wrote:
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:31
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
On Fri, Oct 24, 2008 at 9:54 PM, [off-list ref] wrote:
quoted
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
quoted
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
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:31
On Fri, Oct 24, 2008 at 10:30 PM, Jakub Narebski [off-list ref] 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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:31
On Sat, 25 Oct 2008, Giuseppe Bilotta wrote:
On Fri, Oct 24, 2008 at 10:30 PM, Jakub Narebski [off-list ref] wrote:
quoted
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
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:31
On Sat, Oct 25, 2008 at 11:10 AM, Jakub Narebski [off-list ref] wrote:
On Sat, 25 Oct 2008, Giuseppe Bilotta wrote:
quoted
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