* Re: irc usage..
From: Donnie Berkholz @ 2006-05-22 5:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Yann Dirson, Git Mailing List, Matthias Urlichs, Martin Langhoff,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605212132570.3697@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Linus Torvalds wrote:
> Did you do a "top" at any time just before this all happened? It _sounds_
> like it might actually be a memory leak on the CVS server side, and the
> problem may (or may not) be due to the optimization that keeps a single
> long-running CVS server instance for the whole process.
No. =\ I just started the thing running in a screen session and came
back a few hours later to find it like that.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-22 5:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Donnie Berkholz, Yann Dirson, Git Mailing List, Matthias Urlichs,
Martin Langhoff, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605212132570.3697@g5.osdl.org>
On 5/22/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I wouldn't be in the least surprised if that ends up triggering a slow
> leak in CVS itself, and then CVS runs out of memory.
I'm dying to try this out myself after work. I don't discard that
cvsimport might be stuffing data in an array that grows forever. In
any case you'll hear from me soon.
martin
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 4:50 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Yann Dirson, Git Mailing List, Matthias Urlichs, Martin Langhoff,
Johannes Schindelin
In-Reply-To: <44713BE4.9040505@gentoo.org>
On Sun, 21 May 2006, Donnie Berkholz wrote:
>
> Fortunately the storms haven't been that bad down in Corvallis. cvsps
> also worked fine for me, but git-cvsimport broke in the middle.
Hmm. It's actually possible that it did that for me too - I had put the
cvsimport in an xterm and forgotten about it, and just assumed that the
power failure was what broke it. But maybe it had broken down before that
happened - I just don't have any logs left ;)
> Here's the last bits:
>
> [ snip snip ]
> Commit ID 7a36de9c4c9b93337ed789ae2341cad3d0991c6d
> Unknown: error Cannot allocate memory
> Fetching profiles/package.mask v 1.992
> cat: write error: Broken pipe
Hmm. I don't actually know perl, and my original "cvsimport" script was
actually this funny C program that generated a shell script to do the
import. That worked fine, and had no memory leaks, but it was a truly
hacky thing of horrible beauty. Or rather, it _would_ have been that, if
it had had any beauty to be horrible about. But at least I would have been
able to debug it.
But the perl one I can't parse any more. That said, the whole "Unknown:"
printout seems to come from the subroutine "_line()", which just reads a
line from the cvs server.
Did you do a "top" at any time just before this all happened? It _sounds_
like it might actually be a memory leak on the CVS server side, and the
problem may (or may not) be due to the optimization that keeps a single
long-running CVS server instance for the whole process.
I wouldn't be in the least surprised if that ends up triggering a slow
leak in CVS itself, and then CVS runs out of memory.
That would likely have been obvious in any "top" output just before the
failure.
Smurf, Martin, Dscho.. Any ideas? My old script just ran RCS directly on
the files, and had no issues like that. I'll happily admit that my old
script generator thing was horrible, but it was a lot easier to debug than
the smarter perl script that uses a CVS server connection..
Linus
^ permalink raw reply
* [PATCH] Install git builtins into gitexecdir rather than bindir.
From: Sean @ 2006-05-22 4:42 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP09B22AA86724B4F2C01F7FAE9A0@CEZ.ICE>
Moving "git-cmd" commands out of the path and into a special
git exec path, should include the builtins.
---
Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index d171829..d9b9671 100644
--- a/Makefile
+++ b/Makefile
@@ -628,7 +628,8 @@ install: all
$(MAKE) -C templates install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(bindir_SQ)/$p' && ln '$(DESTDIR_SQ)$(bindir_SQ)/git$X' '$(DESTDIR_SQ)$(bindir_SQ)/$p' ;)
+ ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
+ $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
install-doc:
$(MAKE) -C Documentation install
--
1.3.3.ge95c
^ permalink raw reply related
* [PATCH] Change GIT-VERSION-GEN to call git commands with "git" not "git-".
From: Sean @ 2006-05-22 4:39 UTC (permalink / raw)
To: git
GIT-VERSION-GEN can incorrectly return a default version of
"v1.3.GIT" because it tries to execute git commands using the
"git-cmd" format that expects all git commands to be in the $PATH.
Convert these to "git cmd" format so that a proper answer is
returned even when the git commands have been moved out of the
$PATH and into a $gitexecdir.
---
GIT-VERSION-GEN | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 7fcefcd..a461518 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -5,7 +5,7 @@ DEF_VER=v1.3.GIT
# First try git-describe, then see if there is a version file
# (included in release tarballs), then default
-if VN=$(git-describe --abbrev=4 HEAD 2>/dev/null); then
+if VN=$(git describe --abbrev=4 HEAD 2>/dev/null); then
VN=$(echo "$VN" | sed -e 's/-/./g');
elif test -f version
then
@@ -16,7 +16,7 @@ fi
VN=$(expr "$VN" : v*'\(.*\)')
-dirty=$(sh -c 'git-diff-index --name-only HEAD' 2>/dev/null) || dirty=
+dirty=$(sh -c 'git diff-index --name-only HEAD' 2>/dev/null) || dirty=
case "$dirty" in
'')
;;
--
1.3.3.ge95c
^ permalink raw reply related
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-22 4:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605212053590.3697@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
Linus Torvalds wrote:
>
> On Sun, 21 May 2006, Linus Torvalds wrote:
>> Ok. It's still converting (that's a big archive), but it has passed the
>> cvsps stage without errors for me, and the conversion so far seems ok. But
>> it has only gotten to
>>
>> Author: vapier <vapier> 2002-09-23 12:32:42
>> Changed GPL to GPL-2 in LICENSE and updated SRC_URI to use mirror:
>>
>> so it has converted only slightly more than the first two years of
>> history in the roughly 30 minutes I've let it run. So it will take several
>> hours.
>
> Btw, trying this import (which got interrupted by a thunderstorm and one
> of our first power failures in a long time - just a few seconds, but
> enough to power off everything but my laptops) it became very obvious that
> "git cvsimport" really _really_ should re-pack the archive every once in a
> while.
Fortunately the storms haven't been that bad down in Corvallis. cvsps
also worked fine for me, but git-cvsimport broke in the middle. The
command I'm using is 'git-cvsimport -P ../gentoo.cvsps -k -d
/media/scm_comparison -A ~/dev/Authors -v gentoo-x86 | tee cvsimport.log'
Here's the last bits:
Fetching gnome-base/gnome-applets/gnome-applets-1.4.0.4-r1.ebuild v 1.5
Update gnome-base/gnome-applets/gnome-applets-1.4.0.4-r1.ebuild: 947 bytes
Fetching gnome-base/gnome-applets/gnome-applets-1.4.0.4-r2.ebuild v 1.3
Update gnome-base/gnome-applets/gnome-applets-1.4.0.4-r2.ebuild: 977 bytes
Fetching gnome-base/gnome-applets/gnome-applets-2.0.0-r1.ebuild v 1.2
Update gnome-base/gnome-applets/gnome-applets-2.0.0-r1.ebuild: 2704 bytes
Fetching gnome-base/gnome-applets/gnome-applets-2.0.0.ebuild v 1.2
Update gnome-base/gnome-applets/gnome-applets-2.0.0.ebuild: 3031 bytes
Tree ID 4d19a84efce2de9cfb42ac0397e0036bbed2ad65
Parent ID ecb78bbe30369a76e2599d0d17de8fe922dca211
Committed patch 14615 (origin 2002-07-16 20:13:15)
Commit ID 4dd2179e0c1369e07cd268fb5c8b150c3a2a1094
Delete net-fs/openafs/openafs-1.2.2-r6.ebuild
Delete net-fs/openafs/files/digest-openafs-1.2.2-r6
Tree ID bfc7320883983655d7d2ea2c6d04f85b45365ce1
Parent ID 4dd2179e0c1369e07cd268fb5c8b150c3a2a1094
Committed patch 14616 (origin 2002-07-16 20:15:15)
Commit ID 7a36de9c4c9b93337ed789ae2341cad3d0991c6d
Unknown: error Cannot allocate memory
Fetching profiles/package.mask v 1.992
cat: write error: Broken pipe
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 3:59 UTC (permalink / raw)
To: Donnie Berkholz; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605211209080.3649@g5.osdl.org>
On Sun, 21 May 2006, Linus Torvalds wrote:
>
> Ok. It's still converting (that's a big archive), but it has passed the
> cvsps stage without errors for me, and the conversion so far seems ok. But
> it has only gotten to
>
> Author: vapier <vapier> 2002-09-23 12:32:42
> Changed GPL to GPL-2 in LICENSE and updated SRC_URI to use mirror:
>
> so it has converted only slightly more than the first two years of
> history in the roughly 30 minutes I've let it run. So it will take several
> hours.
Btw, trying this import (which got interrupted by a thunderstorm and one
of our first power failures in a long time - just a few seconds, but
enough to power off everything but my laptops) it became very obvious that
"git cvsimport" really _really_ should re-pack the archive every once in a
while.
The old "repack every month or so" approach doesn't work that well when
you try to import several years of history in a few hours.
Now, you can just repack after the whole thing is done (it will probably
take no more than ~15 minutes or so), but it would probably be best if the
import script itself decided to repack every once in a while just to avoid
wasting a lot of diskspace _during_ the import itself.
So this isn't so much a correctness issue as a "avoid wasting time and
space" issue, but still..
Linus
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 1:45 UTC (permalink / raw)
To: Yann Dirson; +Cc: Git Mailing List
In-Reply-To: <20060520203911.GI6535@nowhere.earth>
On Sat, 20 May 2006, Yann Dirson wrote:
>
> FWIW, I have mentionned a problem that may be the same, under
> Message-ID <20060107090148.GB32585@nowhere.earth>, that was on January
> 7th. Namely, when importing a repository with very large files over
> pserver or ssh, timeouts can occur and prevent the import from
> working. But, as you said, it's not easy to get precise info from the
> logs :)
For big repositories, you really shouldn't use pserver or ssh anyway. You
should try really really hard to just get a local copy, and do it that
way. It's going to be tons faster, and will avoid a lot of the problems,
including network timeouts etc.
Linus
^ permalink raw reply
* Re: Local clone/fetch with cogito is glacial
From: Linus Torvalds @ 2006-05-22 1:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <4470FC21.6010104@zytor.com>
On Sun, 21 May 2006, H. Peter Anvin wrote:
>
> It appears that doing a *local* -- meaning using a file path or file URL --
> clone or fetch with cogito is just glacial when the repository has an even
> moderate number of tags (and it's fetching the tags that takes all the time.)
> That's a really serious problem for me.
I think this is purely a cogito problem.
Use "git clone" instead.
Linus
^ permalink raw reply
* Re: your mail
From: J. Bruce Fields @ 2006-05-22 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk68ehq1f.fsf@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
>
> That's OK. I just cooked up this one ;-).
Thanks!--b.
^ permalink raw reply
* Re: Local clone/fetch with cogito is glacial
From: Sean @ 2006-05-22 1:20 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4470FC21.6010104@zytor.com>
On Sun, 21 May 2006 16:47:45 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:
> It appears that doing a *local* -- meaning using a file path or file URL
> -- clone or fetch with cogito is just glacial when the repository has an
> even moderate number of tags (and it's fetching the tags that takes all
> the time.) That's a really serious problem for me.
>
Peter, does git clone work acceptably for you?
Sean
^ permalink raw reply
* Re: totorial-2 Re: (unknown)
From: J. Bruce Fields @ 2006-05-22 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyj2hp5p.fsf_-_@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 05:35:46PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> > +Besides blobs, trees, and commits, the only remaining type of object
> > +is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
> > +for details.
>
> We have created a tag in tutorial#1, so it _might_ make sense to
> just tell the user to cat-file it.
The example in tutorial.txt is a "lightweight" tag.
The original tutorial.txt (unlike this sequel) doesn't actually try to
stick to a consistent example throughout, so it's awkward to refer back.
Probably something to fix some day....
>
> > +------------------------------------------------
> > +$ git diff
> > +--- a/file.txt
> > ++++ b/file.txt
> > +@@ -1 +1,2 @@
> > + hello world!
> > + +hello world, again
> > +$ git update-index file.txt
> > +$ git diff
> > +------------------------------------------------
>
> Is the second line of the diff " +" intentional? The same
> comment to the example that immediately follows this part.
Oops, no--those look like cut'n'paste errors. Would you like a revised
patch?--b.
^ permalink raw reply
* Re: totorial-2 Re: (unknown)
From: Junio C Hamano @ 2006-05-22 0:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <1148255528.61d5d241.2@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Sun, 21 May 2006 19:49:34 -0400
> Subject: [PATCH 3/3] tutorial: add discussion of index file, object database
Thanks. I like the changes to tutorial.txt too btw.
> @@ -0,0 +1,391 @@
> +A tutorial introduction to git: part two
>...
> +and the contents of these files is just the compressed data plus a
> +header identifying their length and their type. The type is either a
> +blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
> +so next we should look at a commit.
>...
> +Besides blobs, trees, and commits, the only remaining type of object
> +is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
> +for details.
We have created a tag in tutorial#1, so it _might_ make sense to
just tell the user to cat-file it.
> +------------------------------------------------
> +$ git diff
> +--- a/file.txt
> ++++ b/file.txt
> +@@ -1 +1,2 @@
> + hello world!
> + +hello world, again
> +$ git update-index file.txt
> +$ git diff
> +------------------------------------------------
Is the second line of the diff " +" intentional? The same
comment to the example that immediately follows this part.
^ permalink raw reply
* Re: your mail
From: Junio C Hamano @ 2006-05-22 0:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060521235514.GC23096@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
>> >From nobody Mon Sep 17 00:00:00 2001
>> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Oops, sorry, I screwed up sending those; let me know if you'd like them
> resent....
That's OK. I just cooked up this one ;-).
-- >8 --
From 03946787890c12fbb6ecfbe0382cbf02ac209801 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 21 May 2006 17:15:06 -0700
Subject: [PATCH] mailinfo: skip bogus UNIX From line inside body
Sometimes people just include the whole format-patch output in
the commit e-mail. Detect it and skip the bogus ">From " line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
mailinfo.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/mailinfo.c b/mailinfo.c
index b276519..a133e6d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,10 +237,17 @@ static int eatspace(char *line)
#define SEEN_FROM 01
#define SEEN_DATE 02
#define SEEN_SUBJECT 04
+#define SEEN_BOGUS_UNIX_FROM 010
/* First lines of body can have From:, Date:, and Subject: */
static int handle_inbody_header(int *seen, char *line)
{
+ if (!memcmp(">From", line, 5) && isspace(line[5])) {
+ if (!(*seen & SEEN_BOGUS_UNIX_FROM)) {
+ *seen |= SEEN_BOGUS_UNIX_FROM;
+ return 1;
+ }
+ }
if (!memcmp("From:", line, 5) && isspace(line[5])) {
if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
*seen |= SEEN_FROM;
--
1.3.3.g292f
^ permalink raw reply related
* Re: your mail
From: J. Bruce Fields @ 2006-05-21 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1148255528.61d5d241.0@fieldses.org>
On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
Oops, sorry, I screwed up sending those; let me know if you'd like them
resent....
--b.
^ permalink raw reply
* (unknown)
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1148255528.61d5d241.1@fieldses.org>
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 19:49:34 -0400
Subject: [PATCH 3/3] tutorial: add discussion of index file, object database
Add a sequel to tutorial.txt which discusses the index file and
the object database.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
e84a9b9a34794c5b9dd36f6ccc11e60daecd3003
Documentation/Makefile | 1
Documentation/tutorial-2.txt | 391 ++++++++++++++++++++++++++++++++++++++++++
Documentation/tutorial.txt | 28 ++-
3 files changed, 414 insertions(+), 6 deletions(-)
create mode 100644 Documentation/tutorial-2.txt
e84a9b9a34794c5b9dd36f6ccc11e60daecd3003
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c1af22c..2a08f59 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -7,6 +7,7 @@ MAN7_TXT=git.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
ARTICLES = tutorial
+ARTICLES += tutorial-2
ARTICLES += core-tutorial
ARTICLES += cvs-migration
ARTICLES += diffcore
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
new file mode 100644
index 0000000..a3d45ee
--- /dev/null
+++ b/Documentation/tutorial-2.txt
@@ -0,0 +1,391 @@
+A tutorial introduction to git: part two
+========================================
+
+You should work through link:tutorial.html[A tutorial introduction to
+git] before reading this tutorial.
+
+The goal of this tutorial is to introduce two fundamental pieces of
+git's architecture--the object database and the index file--and to
+provide the reader with everything necessary to understand the rest
+of the git documentation.
+
+The git object database
+-----------------------
+
+Let's start a new project and create a small amount of history:
+
+------------------------------------------------
+$ mkdir test-project
+$ cd test-project
+$ git init-db
+defaulting to local storage area
+$ echo 'hello world' > file.txt
+$ git add .
+$ git commit -a -m "initial commit"
+Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+$ echo 'hello world!' >file.txt
+$ git commit -a -m "add emphasis"
+------------------------------------------------
+
+What are the 40 digits of hex that git responded to the first commit
+with?
+
+We saw in part one of the tutorial that commits have names like this.
+It turns out that every object in the git history is stored under
+such a 40-digit hex name. That name is the SHA1 hash of the object's
+contents; among other things, this ensures that git will never store
+the same data twice (since identical data is given an identical SHA1
+name), and that the contents of a git object will never change (since
+that would change the object's name as well).
+
+We can ask git about this particular object with the cat-file
+command--just cut-and-paste from the reply to the initial commit, to
+save yourself typing all 40 hex digits:
+
+------------------------------------------------
+$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
+tree
+------------------------------------------------
+
+A tree can refer to one or more "blob" objects, each corresponding to
+a file. In addition, a tree can also refer to other tree objects,
+thus creating a directory heirarchy. You can examine the contents of
+any tree using ls-tree (remember that a long enough initial portion
+of the SHA1 will also work):
+
+------------------------------------------------
+$ git ls-tree 92b8b694
+100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
+------------------------------------------------
+
+Thus we see that this tree has one file in it. The SHA1 hash is a
+reference to that file's data:
+
+------------------------------------------------
+$ git cat-file -t 3b18e512
+blob
+------------------------------------------------
+
+A "blob" is just file data, which we can also examine with cat-file:
+
+------------------------------------------------
+$ git cat-file blob 3b18e512
+hello world
+------------------------------------------------
+
+Note that this is the old file data; so the object that git named in
+its response to the initial tree was a tree with a snapshot of the
+directory state that was recorded by the first commit.
+
+All of these objects are stored under their SHA1 names inside the git
+directory:
+
+------------------------------------------------
+$ find .git/objects/
+.git/objects/
+.git/objects/pack
+.git/objects/info
+.git/objects/3b
+.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
+.git/objects/92
+.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
+.git/objects/54
+.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
+.git/objects/a0
+.git/objects/a0/423896973644771497bdc03eb99d5281615b51
+.git/objects/d0
+.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
+.git/objects/c4
+.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241
+------------------------------------------------
+
+and the contents of these files is just the compressed data plus a
+header identifying their length and their type. The type is either a
+blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
+so next we should look at a commit.
+
+The simplest commit to find is the HEAD commit, which we can find
+from .git/HEAD:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+As you can see, this tells us which branch we're currently on, and it
+tells us this by naming a file under the .git directory, which itself
+contains a SHA1 name referring to a commit object, which we can
+examine with cat-file:
+
+------------------------------------------------
+$ cat .git/refs/heads/master
+c4d59f390b9cfd4318117afde11d601c1085f241
+$ git cat-file -t c4d59f39
+commit
+$ git cat-file commit c4d59f39
+tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
+parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+
+add emphasis
+------------------------------------------------
+
+The "tree" object here refers to the new state of the tree:
+
+------------------------------------------------
+$ git ls-tree d0492b36
+100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt
+$ git cat-file commit a0423896
+hello world!
+------------------------------------------------
+
+and the "parent" object refers to the previous commit:
+
+------------------------------------------------
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+The tree object is the tree we examined first, and this commit is
+unusual in that it lacks any parent.
+
+Most commits have only one parent, but it is also common for a commit
+to have multiple parents. In that case the commit represents a
+merge, with the parent references pointing to the heads of the merged
+branches.
+
+Besides blobs, trees, and commits, the only remaining type of object
+is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
+for details.
+
+So now we know how git uses the object database to represent a
+project's history:
+
+ * "commit" objects refer to "tree" objects representing the
+ snapshot of a directory tree at a particular point in the
+ history, and refer to "parent" commits to show how they're
+ connected into the project history.
+ * "tree" objects represent the state of a single directory,
+ associating directory names to "blob" objects containing file
+ data and "tree" objects containing subdirectory information.
+ * "blob" objects contain file data without any other structure.
+ * References to commit objects at the head of each branch are
+ stored in files under .git/refs/heads/.
+ * The name of the current branch is stored in .git/HEAD.
+
+Note, by the way, that lots of commands take a tree as an argument.
+But as we can see above, a tree can be referred to in many different
+ways--by the SHA1 name for that tree, by the name of a commit that
+refers to the tree, by the name of a branch whose head refers to that
+tree, etc.--and most such commands can accept any of these names.
+
+In command synopses, the word "tree-ish" is sometimes used to
+designate such an argument.
+
+The index file
+--------------
+
+The primary tool we've been using to create commits is "git commit
+-a", which creates a commit including every change you've made to
+your working tree. But what if you want to commit changes only to
+certain files? Or only certain changes to certain files?
+
+If we look at the way commits are created under the cover, we'll see
+that there are more flexible ways creating commits.
+
+Continuing with our test-project, let's modify file.txt again:
+
+------------------------------------------------
+$ echo "hello world, again" >>file.txt
+------------------------------------------------
+
+but this time instead of immediately making the commit, let's take an
+intermediate step, and ask for diffs along the way to keep track of
+what's happening:
+
+------------------------------------------------
+$ git diff
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
+ +hello world, again
+$ git update-index file.txt
+$ git diff
+------------------------------------------------
+
+The last diff is empty, but no new commits have been made, and the
+head still doesn't contain the new line:
+
+------------------------------------------------
+$ git-diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
+ +hello world, again
+------------------------------------------------
+
+So "git diff" is comparing against something other than the head.
+The thing that it's comparing against is actually the index file,
+which is stored in .git/index in a binary format, but whose contents
+we can examine with ls-files:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+$ git cat-file -t 513feba2
+blob
+$ git cat-file blob 513feba2
+hello world, again
+------------------------------------------------
+
+So what our "git update-index" did was store a new blob and then put
+a reference to it in the index file. If we modify the file again,
+we'll see that the new modifications are reflected in the "git-diff"
+output:
+
+------------------------------------------------
+$ echo 'again?' >>file.txt
+$ git diff
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+With the right arguments, git diff can also show us the difference
+between the working directory and the last commit, or between the
+index and the last commit:
+
+------------------------------------------------
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,3 @@
+ hello world!
++hello world, again
++again?
+$ git diff --cached
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+At any time, we can create a new commit using "git commit" (without
+the -a option), and verify that the state committed only includes the
+changes stored in the index file, not the additional change that is
+still only in our working tree:
+
+------------------------------------------------
+$ git commit -m "repeat"
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+So by default "git commit" uses the index to create the commit, not
+the working tree; the -a option to commit tells it to first update
+the index with all changes in the working tree.
+
+Finally, it's worth looking at the effect of "git add" on the index
+file:
+
+------------------------------------------------
+$ echo "goodbye, world" >closing.txt
+$ git add closing.txt
+------------------------------------------------
+
+The effect of the "git add" was to add one entry to the index file:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+------------------------------------------------
+
+And, as you can see with cat-file, this new entry refers to the
+current contents of the file:
+
+------------------------------------------------
+$ git cat-file blob a6b11f7a
+goodbye, word
+------------------------------------------------
+
+The "status" command is a useful way to get a quick summary of the
+situation:
+
+------------------------------------------------
+$ git status
+#
+# Updated but not checked in:
+# (will commit)
+#
+# new file: closing.txt
+#
+#
+# Changed but not updated:
+# (use git-update-index to mark for commit)
+#
+# modified: file.txt
+#
+------------------------------------------------
+
+Since the current state of closing.txt is cached in the index file,
+it is listed as "updated but not checked in". Since file.txt has
+changes in the working directory that aren't reflected in the index,
+it is marked "changed but not updated". At this point, running "git
+commit" would create a commit that added closing.txt (with its new
+contents), but that didn't modify file.txt.
+
+Also, note that a bare "git diff" shows the changes to file.txt, but
+not the addition of closing.txt, because the version of closing.txt
+in the index file is identical to the one in the working directory.
+
+In addition to being the staging area for new commits, the index file
+is also populated from the object database when checking out a
+branch, and is used to hold the trees involved in a merge operation.
+See the link:core-tutorial.txt[core tutorial] and the relevant man
+pages for details.
+
+What next?
+----------
+
+At this point you should know everything necessary to read the man
+pages for any of the git commands; one good place to start would be
+with the commands mentioned in link:everday.html[Everyday git]. You
+should be able to find any unknown jargon in the
+link:glossary.html[Glosssay].
+
+The link:cvs-migration.html[CVS migration] document explains how to
+import a CVS repository into git, and shows how to use git in a
+CVS-like way.
+
+For some interesting examples of git use, see the
+link:howto-index.html[howtos].
+
+For git developers, the link:core-tutorial.html[Core tutorial] goes
+into detail on the lower-level git mechanisms involved in, for
+example, creating a new commit.
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 4c298c6..79781ad 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -442,7 +442,25 @@ fo the file:
Next Steps
----------
-Some good commands to explore next:
+This tutorial should be enough to perform basic distributed revision
+control for your projects. However, to fully understand the depth
+and power of git you need to understand two simple ideas on which it
+is based:
+
+ * The object database is the rather elegant system used to
+ store the history of your project--files, directories, and
+ commits.
+
+ * The index file is a cache of the state of a directory tree,
+ used to create commits, check out working directories, and
+ hold the various trees involved in a merge.
+
+link:tutorial-2.html[Part two of this tutorial] explains the object
+database, the index file, and a few other odds and ends that you'll
+need to make the most of git.
+
+If you don't want to consider with that right away, a few other
+digressions that may be interesting at this point are:
* gitlink:git-format-patch[1], gitlink:git-am[1]: These convert
series of git commits into emailed patches, and vice versa,
@@ -456,8 +474,6 @@ Some good commands to explore next:
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
-Other good starting points include link:everyday.html[Everday GIT
-with 20 Commands Or So] and link:cvs-migration.html[git for CVS
-users]. Also, link:core-tutorial.html[A short git tutorial] gives an
-introduction to lower-level git commands for advanced users and
-developers.
+ * link:everyday.html[Everday GIT with 20 Commands Or So]
+
+ * link:cvs-migration.html[git for CVS users].
--
1.3.3.gff62
^ permalink raw reply related
* (unknown)
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1148255528.61d5d241.0@fieldses.org>
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:54:05 -0400
Subject: [PATCH 2/3] tutorial: expanded discussion of commit history
Expand the history-browsing section of the tutorial a bit, in part to
address Junio's suggestion that we mention "git grep" and Linus's
complaint that people are missing the flexibility of the commandline
interfaces for selecting commits.
This reads a little more like a collection of examples than a
"tutorial", but maybe that's what people need at this point.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
bb2450ce2145bfdc5b3b7c967a5ed3571437f5d4
Documentation/tutorial.txt | 165 ++++++++++++++++++++++++++++++--------------
1 files changed, 112 insertions(+), 53 deletions(-)
bb2450ce2145bfdc5b3b7c967a5ed3571437f5d4
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index cd0f0df..4c298c6 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -288,103 +288,162 @@ Git can also be used in a CVS-like mode,
that various users push changes to; see gitlink:git-push[1] and
link:cvs-migration.html[git for CVS users].
-Keeping track of history
-------------------------
+Exploring history
+-----------------
-Git history is represented as a series of interrelated commits. The
-most recent commit in the currently checked-out branch can always be
-referred to as HEAD, and the "parent" of any commit can always be
-referred to by appending a caret, "^", to the end of the name of the
-commit. So, for example,
+Git history is represented as a series of interrelated commits. We
+have already seen that the git log command can list those commits.
+Note that first line of each git log entry also gives a name for the
+commit:
-------------------------------------
-git diff HEAD^ HEAD
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date: Tue May 16 17:18:22 2006 -0700
+
+ merge-base: Clarify the comments on post processing.
-------------------------------------
-shows the difference between the most-recently checked-in state of
-the tree and the previous state, and
+We can give this name to git show to see the details about this
+commit.
-------------------------------------
-git diff HEAD^^ HEAD^
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------
-shows the difference between that previous state and the state two
-commits ago. Also, HEAD~5 can be used as a shorthand for HEAD{caret}{caret}{caret}{caret}{caret},
-and more generally HEAD~n can refer to the nth previous commit.
-Commits representing merges have more than one parent, and you can
-specify which parent to follow in that case; see
-gitlink:git-rev-parse[1].
+But there other ways to refer to commits. You can use any initial
+part of the name that is long enough to uniquely identify the commit:
-The name of a branch can also be used to refer to the most recent
-commit on that branch; so you can also say things like
+-------------------------------------
+$ git show c82a22c39c # the first few characters of the name are
+ # usually enough
+$ git show HEAD # the tip of the current branch
+$ git show experimental # the tip of the "experimental" branch
+-------------------------------------
+
+Every commit has at least one "parent" commit, which points to the
+previous state of the project:
-------------------------------------
-git diff HEAD experimental
+$ git show HEAD^ # to see the parent of HEAD
+$ git show HEAD^^ # to see the grandparent of HEAD
+$ git show HEAD~4 # to see the great-great grandparent of HEAD
-------------------------------------
-to see the difference between the most-recently committed tree in
-the current branch and the most-recently committed tree in the
-experimental branch.
+Note that merge commits may have more than one parent:
+
+-------------------------------------
+$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
+$ git show HEAD^2 # show the second parent of HEAD
+-------------------------------------
-But you may find it more useful to see the list of commits made in
-the experimental branch but not in the current branch, and
+You can also give commits names of your own; after running
-------------------------------------
-git log HEAD..experimental
+$ git-tag v2.5 1b2e1d63ff
-------------------------------------
-will do that, just as
+you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
+share this name with other people (for example, to identify a release
+version), you should create a "tag" object, and perhaps sign it; see
+gitlink:git-tag[1] for details.
+
+Any git command that needs to know a commit can take any of these
+names. For example:
-------------------------------------
-git log experimental..HEAD
+$ git diff v2.5 HEAD # compare the current HEAD to v2.5
+$ git branch stable v2.5 # start a new branch named "stable" based
+ # at v2.5
+$ git reset --hard HEAD^ # reset your current branch and working
+ # directory its state at HEAD^
-------------------------------------
-will show the list of commits made on the HEAD but not included in
-experimental.
+Be careful with that last command: in addition to losing any changes
+in the working directory, it will also remove all later commits from
+this branch. If this branch is the only branch containing those
+commits, they will be lost. (Also, don't use "git reset" on a
+publicly-visible branch that other developers pull from, as git will
+be confused by history that disappears in this way.)
-You can also give commits convenient names of your own: after running
+The git grep command can search for strings in any version of your
+project, so
-------------------------------------
-$ git-tag v2.5 HEAD^^
+$ git grep "hello" v2.5
-------------------------------------
-you can refer to HEAD^^ by the name "v2.5". If you intend to share
-this name with other people (for example, to identify a release
-version), you should create a "tag" object, and perhaps sign it; see
-gitlink:git-tag[1] for details.
+searches for all occurences of "hello" in v2.5.
-You can revisit the old state of a tree, and make further
-modifications if you wish, using git branch: the command
+If you leave out the commit name, git grep will search any of the
+files it manages in your current directory. So
-------------------------------------
-$ git branch stable-release v2.5
+$ git grep "hello"
-------------------------------------
-will create a new branch named "stable-release" starting from the
-commit which you tagged with the name v2.5.
+is a quick way to search just the files that are tracked by git.
-You can reset the state of any branch to an earlier commit at any
-time with
+Many git commands also take sets of commits, which can be specified
+in a number of ways. Here are some examples with git log:
-------------------------------------
-$ git reset --hard v2.5
+$ git log v2.5..v2.6 # commits between v2.5 and v2.6
+$ git log v2.5.. # commits since v2.5
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log v2.5.. Makefile # commits since v2.5 which modify
+ # Makefile
-------------------------------------
-This will remove all later commits from this branch and reset the
-working tree to the state it had when the given commit was made. If
-this branch is the only branch containing the later commits, those
-later changes will be lost. Don't use "git reset" on a
-publicly-visible branch that other developers pull from, as git will
-be confused by history that disappears in this way.
+You can also give git log a "range" of commits where the first is not
+necessarily an ancestor of the second; for example, if the tips of
+the branches "stable-release" and "master" diverged from a common
+commit some time ago, then
+
+-------------------------------------
+$ git log stable..experimental
+-------------------------------------
+
+will list commits made in the experimental branch but not in the
+stable branch, while
+
+-------------------------------------
+$ git log experimental..stable
+-------------------------------------
+
+will show the list of commits made on the stable branch but not
+the experimental branch.
+
+The "git log" command has a weakness: it must present commits in a
+list. When the history has lines of development that diverged and
+then merged back together, the order in which "git log" presents
+those commits is meaningless.
+
+Most projects with multiple contributors (such as the linux kernel,
+or git itself) have frequent merges, and gitk does a better job of
+visualizing their history. For example,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+allows you to browse any commits from the last 2 weeks of commits
+that modified files under the "drivers" directory.
+
+Finally, most commands that take filenames will optionally allow you
+to precede any filename by a commit, to specify a particular version
+fo the file:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
Next Steps
----------
Some good commands to explore next:
- * gitlink:git-diff[1]: This flexible command does much more than
- we've seen in the few examples above.
-
* gitlink:git-format-patch[1], gitlink:git-am[1]: These convert
series of git commits into emailed patches, and vice versa,
useful for projects such as the linux kernel which rely heavily
--
1.3.3.gff62
^ permalink raw reply related
* (unknown)
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:52:34 -0400
Subject: [PATCH 1/3] tutorial: replace "whatchanged" by "log"
Junio suggested changing references to git-whatchanged to git-log.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
d1177b299b449e9eb63d963ee118a5e0283aa611
Documentation/tutorial.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
d1177b299b449e9eb63d963ee118a5e0283aa611
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index fa79b01..cd0f0df 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -80,13 +80,13 @@ file; just remove it, then commit.
At any point you can view the history of your changes using
------------------------------------------------
-$ git whatchanged
+$ git log
------------------------------------------------
If you also want to see complete diffs at each step, use
------------------------------------------------
-$ git whatchanged -p
+$ git log -p
------------------------------------------------
Managing branches
@@ -216,7 +216,7 @@ This actually pulls changes from the bra
"master". Alice could request a different branch by adding the name
of the branch to the end of the git pull command line.
-This merges Bob's changes into her repository; "git whatchanged" will
+This merges Bob's changes into her repository; "git log" will
now show the new commits. If Alice has made her own changes in the
meantime, then Bob's changes will be merged in, and she will need to
manually fix any conflicts.
@@ -234,7 +234,7 @@ named bob-incoming. (Unlike git pull, g
of Bob's line of development without doing any merging). Then
-------------------------------------
-$ git whatchanged -p master..bob-incoming
+$ git log -p master..bob-incoming
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -330,13 +330,13 @@ But you may find it more useful to see t
the experimental branch but not in the current branch, and
-------------------------------------
-git whatchanged HEAD..experimental
+git log HEAD..experimental
-------------------------------------
will do that, just as
-------------------------------------
-git whatchanged experimental..HEAD
+git log experimental..HEAD
-------------------------------------
will show the list of commits made on the HEAD but not included in
--
1.3.3.gff62
^ permalink raw reply related
* Local clone/fetch with cogito is glacial
From: H. Peter Anvin @ 2006-05-21 23:47 UTC (permalink / raw)
To: Git Mailing List
It appears that doing a *local* -- meaning using a file path or file URL
-- clone or fetch with cogito is just glacial when the repository has an
even moderate number of tags (and it's fetching the tags that takes all
the time.) That's a really serious problem for me.
-hpa
^ permalink raw reply
* Re: don't accept bogus N in `HEAD~N'
From: Jakub Narebski @ 2006-05-21 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <87d5e7hxhl.fsf_-_@rho.meyering.net>
Jim Meyering wrote:
> In a very shallow audit, I spotted code where overflow was not detected.
> But it's hardly critical.
>
> Currently,
>
> git-diff HEAD HEAD
>
> is equivalent to this
>
> git-diff HEAD HEAD~18446744073709551616 # aka 2^64
>
> Exercising git-rev-parse directly, currently I get this:
>
> $ git-rev-parse --no-flags --sq HEAD~18446744073709551616
> '639ca5497279607665847f2e3a11064441a8f2a6'
>
> It'd be better to produce a diagnostic and fail:
>
> $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null
> fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename
Wouldn't it remove ability to say "to the root commit"?
One can do it now I guess exactly by specyfying overly large N.
Although there should probably be some limit... or not.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] adding NO_INET_NTOP and compat/inet_ntop.c for systems without inet_ntop() (old Cygwin).
From: iler.ml @ 2006-05-21 21:37 UTC (permalink / raw)
To: git; +Cc: iler.ml
For systems which lack inet_ntop(), this adds compat/inet_ntop.c,
and related build constant, NO_INET_NTOP. Older Cygwin(s) lack
inet_ntop().
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
---
Makefile | 3 +
compat/inet_ntop.c | 200 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 compat/inet_ntop.c
7cd8cb466db39e9253d77db1f07f49bce6901731
diff --git a/Makefile b/Makefile
index 8ce27a6..fffb4ab 100644
--- a/Makefile
+++ b/Makefile
@@ -412,6 +412,9 @@ else
ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in6
endif
endif
+ifdef NO_INET_NTOP
+ LIB_OBJS += compat/inet_ntop.o
+endif
ifdef NO_ICONV
ALL_CFLAGS += -DNO_ICONV
diff --git a/compat/inet_ntop.c b/compat/inet_ntop.c
new file mode 100644
index 0000000..ec8c1bf
--- /dev/null
+++ b/compat/inet_ntop.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (c) 1996-1999 by Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
+ * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
+ * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+ * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+ * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+ * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ */
+
+#include <errno.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <stdio.h>
+#include <string.h>
+
+#ifndef NS_INADDRSZ
+#define NS_INADDRSZ 4
+#endif
+#ifndef NS_IN6ADDRSZ
+#define NS_IN6ADDRSZ 16
+#endif
+#ifndef NS_INT16SZ
+#define NS_INT16SZ 2
+#endif
+
+/*
+ * WARNING: Don't even consider trying to compile this on a system where
+ * sizeof(int) < 4. sizeof(int) > 4 is fine; all the world's not a VAX.
+ */
+
+/* const char *
+ * inet_ntop4(src, dst, size)
+ * format an IPv4 address
+ * return:
+ * `dst' (as a const)
+ * notes:
+ * (1) uses no statics
+ * (2) takes a u_char* not an in_addr as input
+ * author:
+ * Paul Vixie, 1996.
+ */
+static const char *
+inet_ntop4(src, dst, size)
+ const u_char *src;
+ char *dst;
+ size_t size;
+{
+ static const char fmt[] = "%u.%u.%u.%u";
+ char tmp[sizeof "255.255.255.255"];
+ int nprinted;
+
+ nprinted = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2], src[3]);
+ if (nprinted < 0)
+ return (NULL); /* we assume "errno" was set by "snprintf()" */
+ if ((size_t)nprinted > size) {
+ errno = ENOSPC;
+ return (NULL);
+ }
+ strcpy(dst, tmp);
+ return (dst);
+}
+
+#ifndef NO_IPV6
+/* const char *
+ * inet_ntop6(src, dst, size)
+ * convert IPv6 binary address into presentation (printable) format
+ * author:
+ * Paul Vixie, 1996.
+ */
+static const char *
+inet_ntop6(src, dst, size)
+ const u_char *src;
+ char *dst;
+ size_t size;
+{
+ /*
+ * Note that int32_t and int16_t need only be "at least" large enough
+ * to contain a value of the specified size. On some systems, like
+ * Crays, there is no such thing as an integer variable with 16 bits.
+ * Keep this in mind if you think this function should have been coded
+ * to use pointer overlays. All the world's not a VAX.
+ */
+ char tmp[sizeof "ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255"], *tp;
+ struct { int base, len; } best, cur;
+ u_int words[NS_IN6ADDRSZ / NS_INT16SZ];
+ int i;
+
+ /*
+ * Preprocess:
+ * Copy the input (bytewise) array into a wordwise array.
+ * Find the longest run of 0x00's in src[] for :: shorthanding.
+ */
+ memset(words, '\0', sizeof words);
+ for (i = 0; i < NS_IN6ADDRSZ; i++)
+ words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3));
+ best.base = -1;
+ cur.base = -1;
+ for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
+ if (words[i] == 0) {
+ if (cur.base == -1)
+ cur.base = i, cur.len = 1;
+ else
+ cur.len++;
+ } else {
+ if (cur.base != -1) {
+ if (best.base == -1 || cur.len > best.len)
+ best = cur;
+ cur.base = -1;
+ }
+ }
+ }
+ if (cur.base != -1) {
+ if (best.base == -1 || cur.len > best.len)
+ best = cur;
+ }
+ if (best.base != -1 && best.len < 2)
+ best.base = -1;
+
+ /*
+ * Format the result.
+ */
+ tp = tmp;
+ for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
+ /* Are we inside the best run of 0x00's? */
+ if (best.base != -1 && i >= best.base &&
+ i < (best.base + best.len)) {
+ if (i == best.base)
+ *tp++ = ':';
+ continue;
+ }
+ /* Are we following an initial run of 0x00s or any real hex? */
+ if (i != 0)
+ *tp++ = ':';
+ /* Is this address an encapsulated IPv4? */
+ if (i == 6 && best.base == 0 &&
+ (best.len == 6 || (best.len == 5 && words[5] == 0xffff))) {
+ if (!inet_ntop4(src+12, tp, sizeof tmp - (tp - tmp)))
+ return (NULL);
+ tp += strlen(tp);
+ break;
+ }
+ tp += snprintf(tp, sizeof tmp - (tp - tmp), "%x", words[i]);
+ }
+ /* Was it a trailing run of 0x00's? */
+ if (best.base != -1 && (best.base + best.len) ==
+ (NS_IN6ADDRSZ / NS_INT16SZ))
+ *tp++ = ':';
+ *tp++ = '\0';
+
+ /*
+ * Check for overflow, copy, and we're done.
+ */
+ if ((size_t)(tp - tmp) > size) {
+ errno = ENOSPC;
+ return (NULL);
+ }
+ strcpy(dst, tmp);
+ return (dst);
+}
+#endif
+
+/* char *
+ * inet_ntop(af, src, dst, size)
+ * convert a network format address to presentation format.
+ * return:
+ * pointer to presentation format address (`dst'), or NULL (see errno).
+ * author:
+ * Paul Vixie, 1996.
+ */
+const char *
+inet_ntop(af, src, dst, size)
+ int af;
+ const void *src;
+ char *dst;
+ size_t size;
+{
+ switch (af) {
+ case AF_INET:
+ return (inet_ntop4(src, dst, size));
+#ifndef NO_IPV6
+ case AF_INET6:
+ return (inet_ntop6(src, dst, size));
+#endif
+ default:
+ errno = EAFNOSUPPORT;
+ return (NULL);
+ }
+ /* NOTREACHED */
+}
--
1.3.GIT
^ permalink raw reply related
* don't accept bogus N in `HEAD~N'
From: Jim Meyering @ 2006-05-21 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bf3jl15.fsf@assigned-by-dhcp.cox.net>
In a very shallow audit, I spotted code where overflow was not detected.
But it's hardly critical.
Currently,
git-diff HEAD HEAD
is equivalent to this
git-diff HEAD HEAD~18446744073709551616 # aka 2^64
Exercising git-rev-parse directly, currently I get this:
$ git-rev-parse --no-flags --sq HEAD~18446744073709551616
'639ca5497279607665847f2e3a11064441a8f2a6'
It'd be better to produce a diagnostic and fail:
$ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 > /dev/null
fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename
The code in question is in sha1_name.c (get_sha1_1):
int num = 0;
...
while (cp < name + len)
num = num * 10 + *cp++ - '0';
Looking at how to fix it, my first reflex was to replace that loop
with this one:
while (cp < name + len) {
int tmp = num * 10 + *cp++ - '0';
if (INT_MAX / 10 < num || tmp < num)
return -1;
num = tmp;
}
But INT_MAX is used nowhere else, so I wonder if git avoids using
it for some reason. At least `make check' gripes about __INT_MAX__.
Anyhow, here's the patch I used. With it, git still passes `make test'.
diff --git a/sha1_name.c b/sha1_name.c
index dc68355..c813ba0 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -429,8 +429,12 @@ static int get_sha1_1(const char *name,
int num = 0;
int len1 = cp - name;
cp++;
- while (cp < name + len)
- num = num * 10 + *cp++ - '0';
+ while (cp < name + len) {
+ int tmp = num * 10 + *cp++ - '0';
+ if (INT_MAX / 10 < num || tmp < num)
+ return -1;
+ num = tmp;
+ }
if (has_suffix == '^') {
if (!num && len1 == len - 1)
num = 1;
^ permalink raw reply related
* Re: synchronizing incremental git changes to cvs
From: Jim Meyering @ 2006-05-21 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7v3bf3jl15.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>> I'd like to develop using git, and have a commit hook mirror the
>> day-to-day changes (tags/commits) made in the git repo to a
>> cvs repository. The idea is that the only way changes get into
>> the cvs repo is via the git commit hook.
>
> I do not use the automated tools myself, but I sync the day-job
> work in my git repository to CVS at work. I do not develop with
> CVS but use it merely as a publishing medium. Although other
> people can make commits into CVS in which case I have to slurp
> the change back into my git repository.
>
> (0) Bootstrap. I did use git-cvsimport myself (this repository
...
> (1) Beginning of the day. In case other people did work on
...
Thank you for describing the process you use.
However, since I don't have to allow independent cvs commits,
I hope to bend git-cvsexportcommit to my needs.
It already does almost everything I want.
> using git-cvsimport), as I do not offhand know how exportcommit
> works. The commits on the git side you would want to push back
> are the ones on "master" but not on "origin", which you can get
> from "git rev-list origin..master", so I presume if you feed
> that to exportcommit things all magically work?
I haven't yet tried to restrict the mirroring to commits on a specific
git branch. So far, in the toy example I'm using to test things,
I have this in .git/hooks/post-commit:
#!/bin/sh
sha1_id=$(git-rev-parse --verify HEAD)
cvsdir=/var/tmp/work-c
cd $cvsdir && GIT_DIR=/var/tmp/git-experiment/work-g/.git \
git-cvsexportcommit -v -c -p $sha1_id
I'll clean up and post the changes I've made to git-cvsexportcommit
this week.
> By the way, I met Paul a few days ago and he mentioned that you
> have some quick audit results on our code from your evaluation.
> Can we expect fixes or at least pointing-out-problems from you
> sometime soon please?
I'll send one report separately.
^ permalink raw reply
* [PATCH] remove superflous "const"
From: Alex Riesen @ 2006-05-21 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
---
Someone probably forgot to clean it up.
8eecc10b942df988c2b6ea1141636f9674094b76
builtin-grep.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8eecc10b942df988c2b6ea1141636f9674094b76
diff --git a/builtin-grep.c b/builtin-grep.c
index d09ddf0..53de8a8 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -518,7 +518,7 @@ static int external_grep(struct grep_opt
argc = nr;
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- const char *name;
+ char *name;
if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
continue;
if (!pathspec_matches(paths, ce->name))
--
1.3.3.g58b5b
^ permalink raw reply related
* Re: irc usage..
From: Linus Torvalds @ 2006-05-21 19:24 UTC (permalink / raw)
To: Donnie Berkholz; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <446FA262.7080900@gentoo.org>
On Sat, 20 May 2006, Donnie Berkholz wrote:
>
> I don't want to post the link publicly for a few reasons, including the
> huge amount of bandwidth it would suck up for lots of people to download
> it. I've sent it to you off-list, and if anyone else would also like it,
> please drop me a note.
Ok. It's still converting (that's a big archive), but it has passed the
cvsps stage without errors for me, and the conversion so far seems ok. But
it has only gotten to
Author: vapier <vapier> 2002-09-23 12:32:42
Changed GPL to GPL-2 in LICENSE and updated SRC_URI to use mirror:
so it has converted only slightly more than the first two years of
history in the roughly 30 minutes I've let it run. So it will take several
hours.
The reason it works for me is likely simply the fact that I had a few
patches to my cvsps already. I'm appending the stupid patches, I'm not
guaranteeing that they are correct at all, although the three _committed_
patches are almost certainly correct (and the last uncommitted one is
almost certainly totally broken). The patches are against clean cvsps 2.1.
Also, when I say "the conversion so far seems ok", I obviously don't
actually know what the hell the archive is supposed to look like, so I can
only say that the end result seems not totally insane.
To do a good conversion, you'll want to make sure that you have a author
name conversion file. See the "-A" flag in "git help cvsimport" (if you
have the man-pages installed).
Linus
---
commit 534120d9a47062eecd7b53fd7ac0b70d97feb4fd
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 11:20:59 2006 -0800
Increase log-length limit to 64kB
Yeah, it should be dynamic. I'm lazy.
---
cvsps_types.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cvsps_types.h b/cvsps_types.h
index b41e2a9..dba145d 100644
--- a/cvsps_types.h
+++ b/cvsps_types.h
@@ -8,7 +8,7 @@ #define CVSPS_TYPES_H
#include <time.h>
-#define LOG_STR_MAX 32768
+#define LOG_STR_MAX 65536
#define AUTH_STR_MAX 64
#define REV_STR_MAX 64
#define MIN(a, b) ((a) < (b) ? (a) : (b))
commit 82fcf7e31bbeae3b01a8656549e9b8fd89d598eb
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 11:23:37 2006 -0800
Improve handling of file collisions in the same patchset
Take the file revision into account.
---
cvsps.c | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index 1e64e3c..c22147e 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2384,8 +2384,31 @@ void patch_set_add_member(PatchSet * ps,
for (next = ps->members.next; next != &ps->members; next = next->next)
{
PatchSetMember * m = list_entry(next, PatchSetMember, link);
- if (m->file == psm->file && ps->collision_link.next == NULL)
- list_add(&ps->collision_link, &collisions);
+ if (m->file == psm->file) {
+ int order = compare_rev_strings(psm->post_rev->rev, m->post_rev->rev);
+
+ /*
+ * Same revision too? Add it to the collision list
+ * if it isn't already.
+ */
+ if (!order) {
+ if (ps->collision_link.next == NULL)
+ list_add(&ps->collision_link, &collisions);
+ return;
+ }
+
+ /*
+ * If this is an older revision than the one we already have
+ * in this patchset, just ignore it
+ */
+ if (order < 0)
+ return;
+
+ /*
+ * This is a newer one, remove the old one
+ */
+ list_del(&m->link);
+ }
}
psm->ps = ps;
commit 3d1ebcef6b4f9f6c9064efd64da4dd30d93c3c96
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 17:20:20 2006 -0800
Fix branch ancestor calculation
Not having any ancestor at all means that any valid ancestor (even of
"depth 0") is fine.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
cvsps.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index c22147e..2695a0f 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2599,7 +2599,7 @@ static void determine_branch_ancestor(Pa
* note: rev is the pre-commit revision, not the post-commit
*/
if (!head_ps->ancestor_branch)
- d1 = 0;
+ d1 = -1;
else if (strcmp(ps->branch, rev->branch) == 0)
continue;
else if (strcmp(head_ps->ancestor_branch, "HEAD") == 0)
uncommitted diff
Author: Linus Torvalds <torvalds@g5.osdl.org>
Probably totally broken dot counting
---
cvsps.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index 2695a0f..2ad1595 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2357,9 +2357,16 @@ static int revision_affects_branch(CvsFi
static int count_dots(const char * p)
{
int dots = 0;
+ int len = strlen(p);
- while (*p)
- if (*p++ == '.')
+ while (len > 2) {
+ if (memcmp(p+len-2, ".1", 2))
+ break;
+ len -= 2;
+ }
+
+ while (len)
+ if (p[--len] == '.')
dots++;
return dots;
@@ -2613,7 +2620,7 @@ static void determine_branch_ancestor(Pa
/* HACK: we sometimes pretend to derive from the import branch.
* just don't do that. this is the easiest way to prevent...
*/
- d2 = (strcmp(rev->rev, "1.1.1.1") == 0) ? 0 : count_dots(rev->rev);
+ d2 = count_dots(rev->rev);
if (d2 > d1)
head_ps->ancestor_branch = rev->branch;
^ permalink raw reply related
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