* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Linus Torvalds @ 2005-04-22 16:13 UTC (permalink / raw)
To: Tomas Mraz; +Cc: Tom Lord, gnu-arch-users, gnu-arch-dev, git
In-Reply-To: <1114069758.5886.9.camel@perun.redhat.usu>
On Thu, 21 Apr 2005, Tomas Mraz wrote:
>
> However you're right that the original structure proposed by Linus is
> too flat.
You're wrong.
The thing is, having 256 sybdirectories already eats one _megabyte_ of
diskspace on common filessystems. If you expand that to be either deeper
(ie subdirectories within subdirectories), or use more than 8 bits for the
first level, you'll be using much more.
A megabyte of diskspace is peanuts for a project like Linux, but I think
it matters for small projects. I want git to work reasonably even for
really trivial stuff.
For example, if you just expand the fan-out to use 12 bits instead of 8,
you're now using 16MB of diskspace just for the directory structure, even
for a trivially small project. I just think that sucks.
Secondly, any sane OS (and filesystem) will look up flat directories
_faster_ than deep directories. Peter Anvid did the testing: a _totally_
flat directory is actually the best-performing one.
I just don't want to go there, because while it's ok to have tens of
thousands of files in one subdirectory, I don't think it's ok to have
hundreds of thousands of files. The 8-bit initial fan-out is very much a
middle ground: we waste some space (and some time) doing it, but it does
make the really horrible case largely go away.
Trust me, the design of git didn't just come out of my *ss. Unlike pretty
much apparently any other SCM engineer in the history of mankind (judging
by the performance crap that is out there), I actually know what performs
well, and I can calculate how much space we waste, and I actually _did_ do
so, and chose a reasonably intelligent middle ground.
You can bicker about the details (should it be 9 bits? should we pack the
names more densely? should we use another algorithm for compression? why
does it bother to use ASCII headers?), but please realize that those are
_details_. And even then, they are details where I bet that I have
selected pretty reasonable initial values.
So my choices may not be optimal, but they are "reasonable across a wide
variety of different parameters". And that includes project size,
filesystem implementation, disk wastage etc etc.
The only "extreme" choice I actually made was to go with the highest
compression level of zlib. I think I made the right choice there too: it
wastes CPU-time, but it's still pretty cheap(*) and keeps getting cheaper.
And we have a much higher read-to-write ratio that most other systems
have.
(*) I'll also argue that one reason even "-9" is cheap is actually that
most of the files we compress are small. All the metadata files are really
quite small, and most source-files tend to be just a few kB in size too -
I personally believe that _big_ files tend to be things that really change
quite seldom (things with big tables like firmware files etc). And for a
small file, it doesn't actually matter that much, the compression window
just can't grow too much.
So people say that "gzip -9" is expensive, but it's really expensive only
for large files. Try it out, it's just a personal pet theory of mine. But
realize that I _do_ generally think things through. I don't just cobble
together random things. There's a real _reason_ why git runs like a bat
out of hell. It was _designed_.
Linus
^ permalink raw reply
* Re: [PATCH] git-pasky debian dir
From: Chris Wright @ 2005-04-22 16:16 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: git
In-Reply-To: <200504220918.06977.jcorbin@wunjo.org>
* Joshua T. Corbin (jcorbin@wunjo.org) wrote:
> After seeing the spec file, I had to do this:
>
> You can get the binary here:
> http://node1.wunjo.org/~jcorbin/git-pasky_0.6.3-1_i386.deb
>
> alternatively you can pull from here:
> rsync://node1.wunjo.org/git/git
>
> It's against b31d16fad0013b3f106b227232559e24daf36962. It installs
> to /usr/bin, but I hacked things about so that *.sh goes
> in /usr/share/git-pasky/scripts. Haven't had many people try it yet, but it
> works for me; this isn't exactly my first debian package, but if anyone sees
> any glaring issues with it, I'd love to hear about it.
>
> --- /dev/null
> +++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/scriptdir.diff
> @@ -0,0 +1,82 @@
> +diff -u a/Makefile b/Makefile
> +--- a/Makefile 2005-04-22 00:59:22.000000000 -0400
> ++++ b/Makefile 2005-04-22 00:59:43.000000000 -0400
> +@@ -18,6 +18,7 @@
> + prefix=$(HOME)
> +
> + bindir=$(prefix)/bin
> ++scriptdir=$(prefix)/share/git-pasky/scripts
> +
> + CC=gcc
> + AR=ar
> +@@ -28,11 +29,11 @@
> + check-files ls-tree merge-base merge-cache unpack-file git-export \
> + diff-cache convert-cache
> +
> +-SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
> +- gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
> +- gitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \
> +- gitapply.sh gitcancel.sh gitXlntree.sh commit-id gitlsremote.sh \
> +- gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
> ++BINSCRIPTS= parent-id tree-id git gitdiff-do commit-id
> ++SCRIPT= gitXnormid.sh gitadd.sh gitaddremote.sh gitcommit.sh gitdiff.sh \
> ++ gitlog.sh gitls.sh gitlsobj.sh gitmerge.sh gitpull.sh gitrm.sh gittag.sh \
> ++ gittrack.sh gitexport.sh gitapply.sh gitcancel.sh gitXlntree.sh \
> ++ gitlsremote.sh gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
> + gitmerge-file.sh
> +
> + COMMON= read-cache.o
> +@@ -80,7 +81,9 @@
> +
> + install: $(PROG) $(GEN_SCRIPT)
> + install -m755 -d $(DESTDIR)$(bindir)
> +- install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(bindir)
> ++ install -m755 -d $(DESTDIR)$(scriptdir)
> ++ install $(PROG) $(BINSCRIPTS) $(DESTDIR)$(bindir)
> ++ install $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(scriptdir)
This whole bit should be formalized. Ideally, I'd like to do /usr/bin/git
frontend, with all scripts in /usr/libexec/git/. However, this requires
something more than hardcoding paths.
> + clean:
> + rm -f *.o mozilla-sha1/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
> +diff -u a/commit-id b/commit-id
> +--- a/commit-id 2005-04-22 00:59:22.000000000 -0400
> ++++ b/commit-id 2005-04-22 01:02:40.000000000 -0400
> +@@ -5,4 +5,4 @@
> + #
> + # Takes the appropriate ID, defaults to HEAD.
> +
> +-gitXnormid.sh -c $1
> ++/usr/share/git-pasky/scripts/gitXnormid.sh -c $1
like this...
> +Common subdirectories: a/contrib and b/contrib
> +Only in b: debian
> +diff -u a/git b/git
> +--- a/git 2005-04-22 00:59:22.000000000 -0400
> ++++ b/git 2005-04-22 01:01:43.000000000 -0400
> +@@ -17,6 +17,7 @@
> + exit 1
> + }
> +
> ++export PATH=/usr/share/git-pasky/scripts:$PATH
Or this...
> + help () {
> + cat <<__END__
> +Common subdirectories: a/mozilla-sha1 and b/mozilla-sha1
> +diff -u a/parent-id b/parent-id
> +--- a/parent-id 2005-04-22 00:59:22.000000000 -0400
> ++++ b/parent-id 2005-04-22 01:02:01.000000000 -0400
> +@@ -7,6 +7,6 @@
> +
> + PARENT="^parent [A-Za-z0-9]{40}$"
> +
> +-id=$(gitXnormid.sh -c $1) || exit 1
> ++id=$(/usr/share/git-pasky/scripts/gitXnormid.sh -c $1) || exit 1
ditto...
> + cat-file commit $id | egrep "$PARENT" | cut -d ' ' -f 2
> +diff -u a/tree-id b/tree-id
> +--- a/tree-id 2005-04-22 00:59:22.000000000 -0400
> ++++ b/tree-id 2005-04-22 01:00:40.000000000 -0400
> +@@ -5,4 +5,4 @@
> + #
> + # Takes ID of the appropriate commit, defaults to HEAD.
> +
> +-gitXnormid.sh $1
> ++/usr/share/git-pasky/scripts/gitXnormid.sh $1
You get the idea ;-) I certainly see how it makes sense for a first
run to get it going. But this will need fixing upstream.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-22 16:16 UTC (permalink / raw)
To: azarah; +Cc: GIT Mailing Lists
In-Reply-To: <1114179795.29271.18.camel@nosferatu.lan>
On Fri, 2005-04-22 at 16:23 +0200, Martin Schlemmer wrote:
> Hi,
>
> This still applies - any reason for not doing this?
Seems like this will break on certain kinds of data. See below.
> if (!pw)
> die("You don't exist. Go away!");
> realgecos = pw->pw_gecos;
> + /* The name is seperated from the room no., tel no, etc via [,;] */
> + if (strchr(realgecos, ','))
> + *strchr(realgecos, ',') = 0;
> + else if (strchr(realgecos, ';'))
> + *strchr(realgecos, ';') = 0;
> len = strlen(pw->pw_name);
> memcpy(realemail, pw->pw_name, len);
> realemail[len] = '@';
Suppose that the GECOS field is:
Hayes, Kyle; Room 42; 424-424-4242; foo bar baz...
You'll search for the first comma, find it, truncate my name to "Hayes",
and continue.
I have seen this kind of GECOS in larger environments where the
individual users are not the ones that administrate their machines.
Using the LastName, FirstName style of name is not rare.
I think you want something like this (not tested):
char *comma,*semi;
comma = strchr(realgecos,',');
semi = strchr(realgecos,';');
if(comma)
if(semi)
/* lastname, firstname; room #; phone # format */
*semi = 0;
else
*comma = 0;
else if(semi)
*semi = 0;
(hopefully Evolution won't trash the indentation...)
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Linus Torvalds @ 2005-04-22 16:22 UTC (permalink / raw)
To: Chris Mason; +Cc: Krzysztof Halasa, git
In-Reply-To: <200504212016.16729.mason@suse.com>
On Thu, 21 Apr 2005, Chris Mason wrote:
>
> We can sort by the files before reading them in, but even if we order things
> perfectly, we're spreading the io out too much across the drive.
No we don't.
It's easy to just copy the repository in a way where this just isn't true:
you sort the objects by how far they are from the current HEAD, and you
just copy the repository in that order ("furthest" objects first - commits
last).
That's what I meant by defragmentation - you can actually do this on your
own, even if your filesystem doesn't support it.
Do it twice a year, and I pretty much guarantee that your performance will
stay pretty constant over time. The one exception is fsck, which doesn't
seek in "history order".
And this works exactly because:
- we don't do no steenking delta's, and don't have deep "chains" of data
to follow. The longest chain we ever have is just a few deep, and it's
trivial to just encourage the filesystem to have recent things together.
- we have an append-only mentality.
In fact, it works for exactly the same reason that makes us able to drop
old history if we want to. We essentially "drop" the history to another
part of the disk.
Linus
^ permalink raw reply
* [PATCH] git-pasky: Add .gitrc directory to allow command defaults like with .cvsrc
From: Fabian Franz @ 2005-04-22 16:28 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
one thing I liked about CVS was its way to configure default parameters for
commands.
And as I really like the colored log output, I wanted it as default.
While .cvsrc parsing would be quite expensive, using a directory + files
should be fairly cheap and result just in one additional stat-call.
So I added "-c" to ~/.gitrc/log and some code to parse this.
Index: git
===================================================================
- --- 0a9ee5a4d947b998a7ce489242800b39f98eeee5/git (mode:100755
sha1:39969debd59ed51c57973c819cdcc3ca8a7da819)
+++ uncommitted/git (mode:100755)
@@ -67,6 +67,7 @@
exit 1
fi
+[ -e "$HOME/.gitrc/$cmd" ] && set -- $(cat "$HOME/.gitrc/$cmd") "$@"
case "$cmd" in
"add") gitadd.sh "$@";;
cu
Fabian
PS: Should the commandline parsing be cleaned up or do you want to do that
after first release of cogito? And if yes, do you want to use "getopts" or
would this be not supported on some systems?
PPS: I'm fairly new to git, how do I create a diff with the signed-by fields
and with what do I need to sign it?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCaSZDI0lSH7CXz7MRAoq8AJwM2lxPfl0ej32WU7q6bh6WIq5+EACgghGn
mvJzbvg6/bxWLFKfsP1ZEeI=
=03wm
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] git-pasky: Add .gitrc directory to allow command defaults like with .cvsrc
From: Petr Baudis @ 2005-04-22 16:38 UTC (permalink / raw)
To: Fabian Franz; +Cc: git
In-Reply-To: <200504221828.51752.FabianFranz@gmx.de>
Dear diary, on Fri, Apr 22, 2005 at 06:28:48PM CEST, I got a letter
where Fabian Franz <FabianFranz@gmx.de> told me that...
> Hi,
Hello,
> PS: Should the commandline parsing be cleaned up or do you want to do that
> after first release of cogito? And if yes, do you want to use "getopts" or
> would this be not supported on some systems?
I want to go for Perl in the longer term.
> PPS: I'm fairly new to git, how do I create a diff with the signed-by fields
> and with what do I need to sign it?
Put
Signed-off-by: Fabian Franz <FabianFranz@gmx.de>
in front of your patch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [git-pasky] updating tree and source files
From: Rhys Hardwick @ 2005-04-22 16:50 UTC (permalink / raw)
To: git
Hi
I have been looking through the scripts, but cannot find out whether when
running: git pull, checkout-cache will be run if the tree is different.
My main question is, if there is a new version on the git server, and i do a
git pull, will this update the source files. Do I have to carry out some
more commands in order for this to happen?
Sorry if this is a really newb question, but hopefully I should catch up soon!
Rhys
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 16:58 UTC (permalink / raw)
To: kyle; +Cc: GIT Mailing Lists
In-Reply-To: <1114186599.31076.409.camel@axer.marchex.com>
[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]
On Fri, 2005-04-22 at 09:16 -0700, Kyle Hayes wrote:
> On Fri, 2005-04-22 at 16:23 +0200, Martin Schlemmer wrote:
> > Hi,
> >
> > This still applies - any reason for not doing this?
>
> Seems like this will break on certain kinds of data. See below.
>
> > if (!pw)
> > die("You don't exist. Go away!");
> > realgecos = pw->pw_gecos;
> > + /* The name is seperated from the room no., tel no, etc via [,;] */
> > + if (strchr(realgecos, ','))
> > + *strchr(realgecos, ',') = 0;
> > + else if (strchr(realgecos, ';'))
> > + *strchr(realgecos, ';') = 0;
> > len = strlen(pw->pw_name);
> > memcpy(realemail, pw->pw_name, len);
> > realemail[len] = '@';
>
> Suppose that the GECOS field is:
>
> Hayes, Kyle; Room 42; 424-424-4242; foo bar baz...
>
> You'll search for the first comma, find it, truncate my name to "Hayes",
> and continue.
>
> I have seen this kind of GECOS in larger environments where the
> individual users are not the ones that administrate their machines.
> Using the LastName, FirstName style of name is not rare.
>
What OS? With Linux at least, this is what chfn's manpage say:
----
The only restriction placed on the contents of the fields is that no control characters may be present,
nor any of comma, colon, or equal sign. The other field does not have this restriction, and is used to
store accounting information used by other applications.
----
Meaning, if they use a ',' in one of the fields (and it is a linux
system with the chfn most probably from the shadow package), then they
are looking for trouble. The only reason I added the ';' was because
somebody said whatever OS used it instead of a ','.
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [git-pasky] updating tree and source files
From: Petr Baudis @ 2005-04-22 17:16 UTC (permalink / raw)
To: Rhys Hardwick; +Cc: git
In-Reply-To: <200504221750.24188.rhys@rhyshardwick.co.uk>
Dear diary, on Fri, Apr 22, 2005 at 06:50:23PM CEST, I got a letter
where Rhys Hardwick <rhys@rhyshardwick.co.uk> told me that...
> Hi
Hello,
> I have been looking through the scripts, but cannot find out whether when
> running: git pull, checkout-cache will be run if the tree is different.
>
> My main question is, if there is a new version on the git server, and i do a
> git pull, will this update the source files. Do I have to carry out some
> more commands in order for this to happen?
>
> Sorry if this is a really newb question, but hopefully I should catch up soon!
git pull will update your working tree if your working tree branch is
tracking the pulled remote branch. If you do just 'git pull', this is
always the case.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Petr Baudis @ 2005-04-22 17:18 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: kyle, GIT Mailing Lists
In-Reply-To: <1114189105.29271.36.camel@nosferatu.lan>
Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Meaning, if they use a ',' in one of the fields (and it is a linux
> system with the chfn most probably from the shadow package), then they
> are looking for trouble. The only reason I added the ';' was because
> somebody said whatever OS used it instead of a ','.
What about just swapping the two tests so that ; is cut off and , only
when no ; is around?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 17:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: kyle, GIT Mailing Lists
In-Reply-To: <20050422171818.GE7173@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Meaning, if they use a ',' in one of the fields (and it is a linux
> > system with the chfn most probably from the shadow package), then they
> > are looking for trouble. The only reason I added the ';' was because
> > somebody said whatever OS used it instead of a ','.
>
> What about just swapping the two tests so that ; is cut off and , only
> when no ; is around?
>
Actually, maybe just leave it. Its not a train smash, and in theory on
linux ';' is a valid char in the gecos.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Edésio Costa e Silva @ 2005-04-22 17:39 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.58.0504220844390.2344@ppc970.osdl.org>
On 4/22/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 21 Apr 2005, Tomas Mraz wrote:
> >
> > However you're right that the original structure proposed by Linus is
> > too flat.
>
> You're wrong.
>
> The thing is, having 256 sybdirectories already eats one _megabyte_ of
> diskspace on common filessystems. If you expand that to be either deeper
> (ie subdirectories within subdirectories), or use more than 8 bits for the
> first level, you'll be using much more.
>
> A megabyte of diskspace is peanuts for a project like Linux, but I think
> it matters for small projects. I want git to work reasonably even for
> really trivial stuff.
>
> For example, if you just expand the fan-out to use 12 bits instead of 8,
> you're now using 16MB of diskspace just for the directory structure, even
> for a trivially small project. I just think that sucks.
What if the directory structure is sparse?
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-22 17:43 UTC (permalink / raw)
To: azarah; +Cc: GIT Mailing Lists
In-Reply-To: <1114189105.29271.36.camel@nosferatu.lan>
On Fri, 2005-04-22 at 18:58 +0200, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 09:16 -0700, Kyle Hayes wrote:
> > Suppose that the GECOS field is:
> >
> > Hayes, Kyle; Room 42; 424-424-4242; foo bar baz...
> >
> > You'll search for the first comma, find it, truncate my name to "Hayes",
> > and continue.
> >
> > I have seen this kind of GECOS in larger environments where the
> > individual users are not the ones that administrate their machines.
> > Using the LastName, FirstName style of name is not rare.
> >
>
> What OS? With Linux at least, this is what chfn's manpage say:
Can't remember, it's been a while (years). We had AIX, Solaris, Linux
and BSD machines at the time. Might have been AIX, I think. The memory
of which OS is vague, but not the annoyance of finding the problem :-(
> ----
> The only restriction placed on the contents of the fields is that no control characters may be present,
> nor any of comma, colon, or equal sign. The other field does not have this restriction, and is used to
> store accounting information used by other applications.
> ----
>
> Meaning, if they use a ',' in one of the fields (and it is a linux
> system with the chfn most probably from the shadow package), then they
> are looking for trouble. The only reason I added the ';' was because
> somebody said whatever OS used it instead of a ','.
>From the AIX version of chfn:
----
You can use any printable characters in the gecos information string
except a : (colon), which is an attribute delimiter.
----
The AIX examples show use of semicolon as a separator.
So, at least on AIX, it is appears valid to use the style I showed
above. I don't have access to Solaris machines right now. The BSD
(FreeBSD 4.11) version of man 5 passwd:
----
The gecos field normally contains comma (`,') separated subfields as
follows:...
----
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: (anal) Q: Are there any coding styles or development guidelines?
From: Linus Torvalds @ 2005-04-22 17:50 UTC (permalink / raw)
To: Klaus Robert Suetterlin; +Cc: Git Mailing List
In-Reply-To: <20050422155845.GC52771@xdt04.mpe-garching.mpg.de>
On Fri, 22 Apr 2005, Klaus Robert Suetterlin wrote:
>
> I'm currently doing a source audit of the git core components.
> Mainly I want to check if I can spot some left over memory leaks.
>
> Unfortunately ;) I didn't find any so far (after reading five files).
>
> Still I did find quite a lot of stuff that lint would most likely
> complain about. Like not checking return values. Should this be
> fixed now or isn't it time to do the cleanup, yet?
I personally don't think we're quite there yet. You'll note that a lot of
routines just call "die()" when they don't find the data they want etc.
All things that we probably will need to clean up eventually, but is fine
for now.
> I also found several literal copies of the same function including
> function name, parameter list, etc. Wouldn't it be better do clean
> those up and put them in a utility.{c,h} file?
Yes, we can start doing things like that, especially if they really _do_
end up making sense in a bigger picture.
Some of that is because I didn't clean up the Makefile until fairly
recently, so it used to be harder than it is now to have a shared object
file. In contrast, now you just add it to the list of library objects, and
off you go.
> A similar problem
> is the continous reimplementation of linked lists, dynamic memory,
> smart strings / vectors, etc.
Sometimes specific duplication is just _easier_ than trying to be clever
and having some generic shared version. For example, there's a few
data-specific versions of "insert into sorted array" there, and the fact
is, they are so simple that it's likely less work to keep them that way
than it would be to create some "generic" thing that did it and was passed
in some descriptor of the data.
Generic routines aren't always good. Sometimes the abstraction ends up
adding more of a mental burden than just doing the thing in a simple way
in the first place.
> And then there are some stale files (i.e. revision.*) that the Changelog
> already mentions as removed, but which are still active in HEAD.
They definitely are _not_ active in HEAD, at least not in my version.
You may have stale copies in your directory, but they should show up as
being stale when you do "show-files --others".
Linus
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-22 17:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Schlemmer, GIT Mailing Lists
In-Reply-To: <20050422171818.GE7173@pasky.ji.cz>
On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Meaning, if they use a ',' in one of the fields (and it is a linux
> > system with the chfn most probably from the shadow package), then they
> > are looking for trouble. The only reason I added the ';' was because
> > somebody said whatever OS used it instead of a ','.
>
> What about just swapping the two tests so that ; is cut off and , only
> when no ; is around?
Even nicer. I like it. Very clean!
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: [PATCH] git-pasky debian dir
From: Joshua T. Corbin @ 2005-04-22 18:00 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050422161635.GA5324@shell0.pdx.osdl.net>
On 22 April 2005 12:16, Chris Wright <chrisw@osdl.org> wrote:
> This whole bit should be formalized.
Agreed, hence why I did it as a package-build-time patch instead of changing
directly in my repository.
> Ideally, I'd like to do /usr/bin/git frontend, with all scripts
> in /usr/libexec/git/.
How standard is this '/usr/libexec'? I have no such directory on my Debian
boxes. If /usr/share rubs you the wroung way, what of
simply /usr/lib/git-pasky?
> However, this requires something more than hardcoding paths.
Definately, and it may not play well with the simpler method of installing to
$HOME/bin. This was just a quick hack as not to pollute /usr/bin with files
that aren't directly executed by the user.
> You get the idea ;-) I certainly see how it makes sense for a first
> run to get it going. But this will need fixing upstream.
This will all be moot when cogito goes the way of cg-* ;-)
Cheers,
Josh
--
Regards,
Joshua T. Corbin <jcorbin@wunjo.org>
^ permalink raw reply
* [FYI] Cogito rsync/download location moved
From: Petr Baudis @ 2005-04-22 18:00 UTC (permalink / raw)
To: git
Hello,
I'm happy to announce that the Cogito rsync location changed to
rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
Please update your .git/remotes accordingly.
Also please note that the Cogito download location changed too. From
now on, Cogito releases will appear at
http://www.kernel.org/pub/software/scm/cogito
or
ftp://ftp.kernel.org/pub/software/scm/cogito
Please update your bookmarks, if you have any.
This will hopefully make me fit to my bandwidth limit until the end of
the month, and should make things significantly faster for you. Thanks a
lot to the kernel.org folks who made it possible!
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH] Constify
From: Morten Welinder @ 2005-04-22 18:08 UTC (permalink / raw)
To: GIT Mailing List
Hi!
This patch makes strings type "const char *" and keeps people honest.
[Here's to hoping that nothing in this email setup mangles whitespace...]
Signed-off-by: Morten Welinder (mwelinder@gmail.com)
Index: Makefile
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/Makefile (mode:100644
sha1:2d7e4cf0464c45b7c5b169bff7e5c4e7768c13a1)
+++ uncommitted/Makefile (mode:100664)
@@ -12,7 +12,7 @@
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
-CFLAGS=-g -O2 -Wall
+CFLAGS=-g -O2 -Wall -Wwrite-strings
# Should be changed to /usr/local
prefix=$(HOME)
Index: commit-tree.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/commit-tree.c
(mode:100644 sha1:c0b07f89286c3f6cceae8122b4c3142c8efaf8e1)
+++ uncommitted/commit-tree.c (mode:100664)
@@ -62,7 +62,7 @@
return i;
}
-static void finish_buffer(char *tag, char **bufp, unsigned int *sizep)
+static void finish_buffer(const char *tag, char **bufp, unsigned int *sizep)
{
int taglen;
int offset;
@@ -273,7 +273,7 @@
*/
#define MAXPARENT (16)
-static char *commit_tree_usage = "commit-tree <sha1> [-p <sha1>]* < changelog";
+static const char *commit_tree_usage = "commit-tree <sha1> [-p
<sha1>]* < changelog";
int main(int argc, char **argv)
{
Index: diff-cache.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/diff-cache.c
(mode:100644 sha1:5e1d1a6e6d83291964dca82e6969e576f6a839ec)
+++ uncommitted/diff-cache.c (mode:100664)
@@ -215,7 +215,7 @@
return 0;
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static const char *diff_cache_usage = "diff-cache [-r] [-z]
[--cached] <tree sha1>";
int main(int argc, char **argv)
{
Index: diff-tree.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/diff-tree.c (mode:100644
sha1:0f370927dd2496a420af53d137676b6c3c445f75)
+++ uncommitted/diff-tree.c (mode:100664)
@@ -178,7 +178,7 @@
return retval;
}
-static char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1> <tree sha1>";
+static const char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1>
<tree sha1>";
int main(int argc, char **argv)
{
Index: fsck-cache.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/fsck-cache.c
(mode:100644 sha1:96b8eb161107cd3219975d93a44874a5455b702e)
+++ uncommitted/fsck-cache.c (mode:100664)
@@ -134,7 +134,7 @@
int main(int argc, char **argv)
{
int i, heads;
- char *sha1_dir;
+ const char *sha1_dir;
sha1_dir = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
for (i = 0; i < 256; i++) {
Index: init-db.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/init-db.c (mode:100644
sha1:dad06351ca35d0d2f68cd9e719c49805386f96fa)
+++ uncommitted/init-db.c (mode:100664)
@@ -5,7 +5,7 @@
*/
#include "cache.h"
-void safe_create_dir(char *dir)
+void safe_create_dir(const char *dir)
{
if (mkdir(dir, 0755) < 0) {
if (errno != EEXIST) {
@@ -23,7 +23,8 @@
*/
int main(int argc, char **argv)
{
- char *sha1_dir, *path;
+ const char *sha1_dir;
+ char *path;
int len, i;
safe_create_dir(".git");
Index: read-tree.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/read-tree.c (mode:100644
sha1:7c938491ad358582c610edac4a36a03868f8631d)
+++ uncommitted/read-tree.c (mode:100664)
@@ -221,7 +221,7 @@
}
}
-static char *read_tree_usage = "read-tree (<sha> | -m <sha1> [<sha2> <sha3>])";
+static const char *read_tree_usage = "read-tree (<sha> | -m <sha1>
[<sha2> <sha3>])";
int main(int argc, char **argv)
{
Index: sha1_file.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/sha1_file.c (mode:100644
sha1:f356acc9e6ce705fdfb947a5f36bba66fd9cd797)
+++ uncommitted/sha1_file.c (mode:100664)
@@ -61,7 +61,7 @@
static char *name, *base;
if (!base) {
- char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? :
DEFAULT_DB_ENVIRONMENT;
+ const char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? :
DEFAULT_DB_ENVIRONMENT;
int len = strlen(sha1_file_directory);
base = malloc(len + 60);
memcpy(base, sha1_file_directory, len);
Index: show-diff.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/show-diff.c (mode:100644
sha1:da364e26e28823f951a6be1b686a458575f28ea1)
+++ uncommitted/show-diff.c (mode:100664)
@@ -5,10 +5,10 @@
*/
#include "cache.h"
-static char *diff_cmd = "diff -L 'a/%s' -L 'b/%s' ";
-static char *diff_opts = "-p -u";
-static char *diff_arg_forward = " - '%s'";
-static char *diff_arg_reverse = " '%s' -";
+static const char *diff_cmd = "diff -L 'a/%s' -L 'b/%s' ";
+static const char *diff_opts = "-p -u";
+static const char *diff_arg_forward = " - '%s'";
+static const char *diff_arg_reverse = " '%s' -";
static void prepare_diff_cmd(void)
{
@@ -35,15 +35,16 @@
* a b ==> a b ==> 'a b'
* a'b ==> a'\''b ==> 'a'\''b'
*/
-static char *sq_expand(char *src)
+static char *sq_expand(const char *src)
{
static char *buf = NULL;
int cnt, c;
char *cp;
+ const char *sp;
/* count bytes needed to store the quoted string. */
- for (cnt = 1, cp = src; *cp; cnt++, cp++)
- if (*cp == '\'')
+ for (cnt = 1, sp = src; *sp; cnt++, sp++)
+ if (*sp == '\'')
cnt += 3;
if (! (buf = malloc(cnt)))
@@ -61,13 +62,13 @@
return buf;
}
-static void show_differences(char *name, char *label, void *old_contents,
+static void show_differences(const char *name, char *label, void *old_contents,
unsigned long long old_size, int reverse)
{
FILE *f;
char *name_sq = sq_expand(name);
char *label_sq = (name != label) ? sq_expand(label) : name_sq;
- char *diff_arg = reverse ? diff_arg_reverse : diff_arg_forward;
+ const char *diff_arg = reverse ? diff_arg_reverse : diff_arg_forward;
int cmd_size = strlen(name_sq) + strlen(label_sq) * 2 +
strlen(diff_cmd) + strlen(diff_opts) + strlen(diff_arg);
char *cmd = malloc(cmd_size);
Index: update-cache.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/update-cache.c
(mode:100644 sha1:9ad4ae278703ee621b723afc65f3a51038e30f52)
+++ uncommitted/update-cache.c (mode:100664)
@@ -25,9 +25,11 @@
void *in;
SHA_CTX c;
- in = "";
if (size)
in = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+ else
+ in = (void *)"";
+
close(fd);
if (!out || (int)(long)in == -1)
return -1;
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Martin Uecker @ 2005-04-22 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <m3vf6frvxu.fsf@defiant.localdomain>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Fri, Apr 22, 2005 at 11:40:29AM +0200, Krzysztof Halasa wrote:
> > This is why I absolutely do not believe in arguments like "if your
> > filesystem doesn't do tail packing, you shouldn't use it" or "if your
> > don't have name hashing enabled in your filesystem it's broken".
>
> Of course. But one may consider using a filesystem with, say, different
> settings. Or a special filesystem for this task, such as CNFS used by
> news servers (it seems news servers do quite the same what git does,
> except they also purge old contents, i.e., container files don't grow up).
and nttp would give a nice transfer method for git objects...
Martin
--
One night, when little Giana from Milano was fast asleep,
she had a strange dream.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [git pasky] tarball question
From: Greg KH @ 2005-04-22 18:23 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists, Petr Baudis
In-Reply-To: <1114180303.29271.25.camel@nosferatu.lan>
On Fri, Apr 22, 2005 at 04:31:43PM +0200, Martin Schlemmer wrote:
> Hi,
>
> I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with
> the .git database included as well (btw, great stuff renaming it to
> something more distributable), but its going to be a pita for users of
> source based distro's like us (Gentoo), as well as our mirrors if it
> gets much bigger. (Already asked r3pek to add it to portage).
Ah good, I was already makeing a ebuild for it, I'll let others do it
then :)
> How about ripping the .git directory from the next release, and just
> have a un-numbered tarball (like you used to) that have the latest
> snapshot of the .git directory for those that want to do git-pasky
> development? Should even make things easier your side, as you could
> just do a cron to update it one a day/whatever.
Why? The .git directory doesn't hurt anything that gentoo would do, we
would just update the ebuild for the major releases.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] git-pasky debian dir
From: Chris Wright @ 2005-04-22 18:45 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: Chris Wright, git
In-Reply-To: <200504221400.11507.jcorbin@wunjo.org>
* Joshua T. Corbin (jcorbin@wunjo.org) wrote:
> On 22 April 2005 12:16, Chris Wright <chrisw@osdl.org> wrote:
> > This whole bit should be formalized.
> Agreed, hence why I did it as a package-build-time patch instead of changing
> directly in my repository.
>
> > Ideally, I'd like to do /usr/bin/git frontend, with all scripts
> > in /usr/libexec/git/.
> How standard is this '/usr/libexec'? I have no such directory on my Debian
> boxes. If /usr/share rubs you the wroung way, what of
> simply /usr/lib/git-pasky?
Hrm, it's not in FHS, but it's certainly in use on my install:
$ find /usr/libexec | wc -l
122
I don't care too much, I imagine distros wind up customizing this
anyway.
> > However, this requires something more than hardcoding paths.
> Definately, and it may not play well with the simpler method of installing to
> $HOME/bin. This was just a quick hack as not to pollute /usr/bin with files
> that aren't directly executed by the user.
Yup, that's why I dropped 'em in /usr/local/bin for now.
> > You get the idea ;-) I certainly see how it makes sense for a first
> > run to get it going. But this will need fixing upstream.
> This will all be moot when cogito goes the way of cg-* ;-)
Hrm...good point.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [git pasky] tarball question
From: Martin Schlemmer @ 2005-04-22 18:51 UTC (permalink / raw)
To: Greg KH; +Cc: GIT Mailing Lists, Petr Baudis
In-Reply-To: <20050422182353.GA599@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Fri, 2005-04-22 at 11:23 -0700, Greg KH wrote:
> On Fri, Apr 22, 2005 at 04:31:43PM +0200, Martin Schlemmer wrote:
Hi,
> > How about ripping the .git directory from the next release, and just
> > have a un-numbered tarball (like you used to) that have the latest
> > snapshot of the .git directory for those that want to do git-pasky
> > development? Should even make things easier your side, as you could
> > just do a cron to update it one a day/whatever.
>
> Why? The .git directory doesn't hurt anything that gentoo would do, we
> would just update the ebuild for the major releases.
>
True, but the tarball was already nearing 2mb (the one before the
versioned tarballs I still have here, is about 1.8mb), and I was just
afraid of what might have happened size wise by the time it hit version
1.0 :)
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Chris Mason @ 2005-04-22 18:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Krzysztof Halasa, git
In-Reply-To: <Pine.LNX.4.58.0504220916060.2344@ppc970.osdl.org>
On Friday 22 April 2005 12:22, Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Chris Mason wrote:
> > We can sort by the files before reading them in, but even if we order
> > things perfectly, we're spreading the io out too much across the drive.
>
> No we don't.
>
> It's easy to just copy the repository in a way where this just isn't true:
> you sort the objects by how far they are from the current HEAD, and you
> just copy the repository in that order ("furthest" objects first - commits
> last).
>
> That's what I meant by defragmentation - you can actually do this on your
> own, even if your filesystem doesn't support it.
This certainly can help. Based on some ideas from andrea I made a poor man's
defrag script last year that was similar. It worked by copying files into a
flat dir in the order you expected to read them in, deleting the original,
then hard linking them into their original name.
Copying in order straight into a new git tree doesn't help much when the
filesystem is using the subdirectory as a hint to block allocation. So
you'll probably have to copy them all into a flat directory and then hard
link back into the git tree (the flat dir can then be deleted of course).
The problem I see for git is that once you have enough data, it should degrade
over and over again somewhat quickly. My own guess is that you'll need to
run the script at least monthly. If we're designing the thing now and say
'wow, that's going to be really slow without help', it doesn't hurt to look
at alternatives.
I grabbed Ingo's tarball of 28,000 patches since 2.4.0 and applied them all
into git on ext3 (htree). It only took ~2.5 hrs to apply. I did use my
write-tree patch where you had to give write-tree a list of directories to
search, but I don't think this helped much since the operation was mostly
disk write bound.
Anyway, I ended up with a 2.6GB .git directory. Then I:
rm .git/index
umount ; mount again
time read-tree `tree-id` (24.45s)
time checkout-cache --prefix=../checkout/ -a -f (4m30s)
--prefix is neat ;)
The tree that ended up in checkout was 239456k, giving us an effective io rate
for checkout-cache of 885k/s. (this drive gets 24MB/s sequential reads).
I'll have numbers for the packed files later on today. No, I don't really
expect the numbers will convince you to implement some kind of packing ;)
But it's still a good data point to have, and generating them here is just
poking the box every 2 hours or so.
-chris
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 19:06 UTC (permalink / raw)
To: kyle; +Cc: Petr Baudis, GIT Mailing Lists
In-Reply-To: <1114192702.31076.428.camel@axer.marchex.com>
[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]
On Fri, 2005-04-22 at 10:58 -0700, Kyle Hayes wrote:
> On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
> > where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > > Meaning, if they use a ',' in one of the fields (and it is a linux
> > > system with the chfn most probably from the shadow package), then they
> > > are looking for trouble. The only reason I added the ';' was because
> > > somebody said whatever OS used it instead of a ','.
> >
> > What about just swapping the two tests so that ; is cut off and , only
> > when no ; is around?
>
> Even nicer. I like it. Very clean!
>
Right, but ';' is not cutoff on linux for one, and from what you said
freebsd as well. How about this rather (note that I assumed that the
use of ';' as delimiter will be in the minority, but we can switch
things around if it turns out the other way):
----
(not signed off, etc, as just for comments)
Index: commit-tree.c
===================================================================
--- 5f61aecb06c2f2579bbb5951b1b53e0dedc434eb/commit-tree.c (mode:100644 sha1:c0b07f89286c3f6cceae8122b4c3142c8efaf8e1)
+++ uncommitted/commit-tree.c (mode:100644)
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -311,6 +296,17 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /*
+ * The GECOS fields are seperated via ',' on Linux, FreeBSD, etc,
+ * and ';' on AIX.
+ */
+#if defined(__aix__)
+ if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
+#else
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+#endif
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Linus Torvalds @ 2005-04-22 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzmvr72j6.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Apr 2005, Junio C Hamano wrote:
>
> The commands I would want to take paths relative to the user cwd
> are quite limited; note that I just want these available to the
> user and I do not care which one, the core or Cogito, groks the
> cwd relative paths:
I've thought about this, and looked at the sources, and it wouldn't be
horrible.
HOWEVER, the more I thought about it, the less sense it made. The fact is,
you can do _exactly_ what you are talking about by just wrapping the calls
in
( cd $WORKING_DIR && git-cmd )
which simply doesn't have any downsides that I can see. It always does the
right thing, and it means that the tools will never have to care about
what the base is. Keeping the core tools is important, because if they
mess up, you're in serious trouble. In contrast, if higher levels mess up,
you're not likely to have caused anything irrevocable.
In fact, I probably shouldn't even have done the "--prefix=" stuff for
check-out, since the common "check out in a new directory" case (not the
"prefix file" case can be pretty easily emulated with a fairly trivial
script, something like
#!/bin/sh
CURRENT_DIR=$(pwd)
GIT_INDEX_FILE=${GIT_INDEX_FILE:-$CURRENT_DIR/.git/index}
SHA1_FILE_DIRECTORY=${SHA1_FILE_DIRECTORY:-$CURRENT_DIR/.git/objects}
TARGET=$1
shift 1
mkdir $TARGET && cd $TARGET && checkout-cache "$@"
but since it was (a) very easy to add to that particular program, and (b)
exporting a while directory is pretty fundamental, I'll just leave that
strange special case around.
So to the core tools, there really _are_ just two special things: the
index file, and the place where to find the sha1 objects. The working
directory is really nothing but "pwd", which can be trivially changed
before invocation, ie the addition of a new environment variable really
doesn't _buy_ anything except for complexity.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox