[ANNOUNCE] git-pasky-0.7

[ANNOUNCE] git-pasky-0.7

[Petr Baudis]

  Hello,

  this is the last release of git-pasky, my SCMish layer over Linus' git
tree history storage tool. The next releases will be called 'cogito' and
will feature a significantly reworked user interface (finally). Get
git-pasky-0.7 at

	http://www.kernel.org/pub/software/scm/cogito

or

	ftp://ftp.kernel.org/pub/software/scm/cogito

  You can also pull, but actually you might as well not want to do that
if you don't know that you will be able to recover possible
inconsistencies (for no local changes, read-tree $(tree-id) &&
checkout-cache -f -a && update-cache --refresh should do). The
pulling/merging tools in older versions contain bugs which _might_
affect this pull.

  The biggest change is in the way the directory cache is used (this is
internal thing, nothing user-visible except less bugs). Now that we have
diff-cache, git-pasky uses that instead of show-diff, and drops the
add/rm queues. This also makes the diffs coming from git diff more
consistent-looking.

  To pick randomly from the other changes - older zlib compatibility,
always use bash, git patch output changes/fixes, git log timezone fix,
plenty of bugfixes and of course merges with Linus. Thanks to all the
contributors!

  Have fun,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.7

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Sun, 2005-04-24 at 02:59 +0200, Petr Baudis wrote:
>   Hello,
> 
>   this is the last release of git-pasky, my SCMish layer over Linus' git
> tree history storage tool. The next releases will be called 'cogito' and
> will feature a significantly reworked user interface (finally). Get
> git-pasky-0.7 at
> 

Over here gitmerge-file.sh is looking for a 'merge' command not present.


Cheers,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] git-pasky-0.7

[Linus Torvalds]

On Sun, 24 Apr 2005, Martin Schlemmer wrote:
> 
> Over here gitmerge-file.sh is looking for a 'merge' command not present.

It's usually packaged up with RCS. So in that sense git does need RCS,
although it's really only the traditional three-way merge program it
wants.

Do "yum install rcs" and you should get it (or whatever your local 
alternative is).

		Linus

Re: [ANNOUNCE] git-pasky-0.7

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Sat, 2005-04-23 at 20:45 -0700, Linus Torvalds wrote:
> 
> On Sun, 24 Apr 2005, Martin Schlemmer wrote:
> > 
> > Over here gitmerge-file.sh is looking for a 'merge' command not present.
> 
> It's usually packaged up with RCS. So in that sense git does need RCS,
> although it's really only the traditional three-way merge program it
> wants.
> 

Thanks, thought it was something like this, but did not see a new
dependency in the README.


Thanks,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] git-pasky-0.7

[Paul Jackson]

I'm missing something here (well, missing alot, but ...).

What are the exact steps, given that I have an empty chunk
of diskspace, to get Linux 2.6.12-rc3 to appear there, using
git.

Actually, I got part way.  Perhaps someone can complete
the following:

    mkdir git
    cd git
    curl -O ftp://ftp.kernel.org/pub/software/scm/cogito/git-pasky-0.6.3.tar.bz2
    tar xvfj git-pasky-0.6.3.tar.bz2
    cd git-pasky-0.6.3
    ls -l /usr/local/include/openssl/sha.h	 # yup - I have openssl header
    make
    ./git init rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
    make install
    git addremote pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
    git pull pasky
    git addremote linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    git pull linus

And I have the SHA1 for Linus's 2.6.12-rc3:

    a2755a80f40e5794ddc20e00f781af9d6320fafb

And I've set DB_ENVIRONMENT=<this-git-directory>/.git/objects

Now I'd like to get 2.6.12-rc3 working kernel files to appear
in a separate directory.

Now what ... how do I do that?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.7

[James Purser]

Try separating out the git directory and linux directory. As I
understand it each project/git repo needs its own directory.
-- 
James Purser
http://ksit.dynalias.com

Re: [ANNOUNCE] git-pasky-0.7

[Paul Jackson]

James wrote:
> Try separating out the git directory and linux directory. As I
> understand it each project/git repo needs its own directory.

I'm willing to do that - but I still don't get what I actually type.

I just tried:

    mkdir linux
    cd linux
    git init

    git addremote linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    # The above complained:
    #	grep: .git/remotes: No such file or directory
    # but still seemed to work ?

    git pull linus	# seems to get the same files I pulled before ... ok.
    # The above complained:
    #	client: nothing to do: perhaps you need to specify some filenames or the --recursive option?


Now what?  I still don't have the working source files for a kernel,
and I don't see how to specify in particular whatever Linus meant by

	a2755a80f40e5794ddc20e00f781af9d6320fafb

I issued a 'git --help' command (yeah - git is different - should be 'git help')
but I don't see any command that looks like it would checkout the working files.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.7

[Daniel Barkalow]

On Sat, 23 Apr 2005, Paul Jackson wrote:

> I'm missing something here (well, missing alot, but ...).
> 
> What are the exact steps, given that I have an empty chunk
> of diskspace, to get Linux 2.6.12-rc3 to appear there, using
> git.
> 
> Actually, I got part way.  Perhaps someone can complete
> the following:
> 
>     mkdir git
>     cd git
>     curl -O ftp://ftp.kernel.org/pub/software/scm/cogito/git-pasky-0.6.3.tar.bz2
>     tar xvfj git-pasky-0.6.3.tar.bz2
>     cd git-pasky-0.6.3
>     ls -l /usr/local/include/openssl/sha.h	 # yup - I have openssl header
>     make
>     ./git init rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
>     make install
>     git addremote pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
>     git pull pasky

You might need a "git seek" or a "git cancel" or a "git track
pasky" here; make sure that VERSION is 0.7.

Then do make install again (to install the 0.7 version that you just got).

Then you want to go into the directory you want linux in:

  cd ..
  mkdir linux
  cd linux

And get a version of Linux:

  git init linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

(IIRC; I've only really worked on git with git)

If you do another addremote in the git directory, it will think that both
remote repositories are for different versions of the same project, and it
will be unhappy with the fact that they are completely unrelated.

	-Daniel
*This .sig left intentionally blank*

Re: [ANNOUNCE] git-pasky-0.7

[Paul Jackson]

Daniel wrote:
> You might need a "git seek" or a "git cancel" or a "git track
> pasky" here; make sure that VERSION is 0.7.

Ok - I typed some random combination of "git seek", "git cancel" and
"git track pasky" and now I have a file named VERSION containing the
string "0.7\n", and I did a make install, with apparently useful
results (built and installed a bunch of stuff).

Then I did the following, with immediate, but not apparently useful, results:

    $ rm -fr linux
    $ mkdir linux
    $ cd linux
    $ git init linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    defaulting to local storage area
    link_stat linus/HEAD : No such file or directory
    rsync error: some files could not be transferred (code 23) at main.c(620)
    gitpull.sh: unable to get the head pointer of branch master
    gitinit.sh: pull failed

Still stuck ...

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.7

[James Purser]

try git init rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
-- 
James Purser
http://ksit.dynalias.com

Re: [ANNOUNCE] git-pasky-0.7

[Paul Jackson]

The winning solution via private email:

	mkdir linux
	cd linux
	git init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Another email was missing the 'scm' term.

I still don't see how to get to the official 2.6.12-rc3:

	a2755a80f40e5794ddc20e00f781af9d6320fafb

But it looks like a kernel now - thanks !!

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.7

[Greg KH]

On Sat, Apr 23, 2005 at 10:02:36PM -0700, Paul Jackson wrote:
> The winning solution via private email:
> 
> 	mkdir linux
> 	cd linux
> 	git init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> Another email was missing the 'scm' term.
> 
> I still don't see how to get to the official 2.6.12-rc3:
> 
> 	a2755a80f40e5794ddc20e00f781af9d6320fafb

 From your "linux" directory do:
 	cd ..
	mkdir 2.6.12-rc3
	cd 2.6.12-rc3
	mkdir .git
	cp -rl ../linux/.git/object .git/objects
	TREE_HEAD=`cat-file commit a2755a80f40e5794ddc20e00f781af9d6320fafb | head -n 1 | cut -f 2 -d " "`
	echo "$TREE_HEAD" > .git/HEAD
	read-tree $TREE_HEAD
	checkout-cache -a
	update-cache --refresh

And you should have a 2.6.12-rc3 tree, all ready to commit new changes
into.

Or at least that's how my wrapper scripts do it, I haven't converted
them over to the "easier" git-pasky commands yet :)

thanks,

greg k-h

Re: [ANNOUNCE] git-pasky-0.7

[Daniel Barkalow]

On Sat, 23 Apr 2005, Paul Jackson wrote:

> I still don't see how to get to the official 2.6.12-rc3:
> 
> 	a2755a80f40e5794ddc20e00f781af9d6320fafb

You've got the current head, which is a couple of days past 2.6.12-rc3. If
you actually want the release version, 

  git seek a2755a80f40e5794ddc20e00f781af9d6320fafb

should get you there, although it will not want to let you commit changes
when you are blatantly not up-to-date.

	-Daniel
*This .sig left intentionally blank*

Re: [ANNOUNCE] git-pasky-0.7

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Sat, 2005-04-23 at 22:02 -0700, Paul Jackson wrote:
> The winning solution via private email:
> 
> 	mkdir linux
> 	cd linux
> 	git init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> Another email was missing the 'scm' term.
> 
> I still don't see how to get to the official 2.6.12-rc3:
> 
> 	a2755a80f40e5794ddc20e00f781af9d6320fafb
> 

If you want a new directory that only goes to official 2.6.12-rc3, try:

    git fork linux-2.6.12-rc3 ../linux-2.6.12-rc3 a2755a80f40e5794ddc20e00f781af9d6320fafb

This will also share the object database, so only space for the checked
out files will be needed.


Cheers,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] git-pasky-0.7

[Petr Baudis]

Dear diary, on Sun, Apr 24, 2005 at 05:58:47AM CEST, I got a letter
where Paul Jackson <pj@sgi.com> told me that...
> What are the exact steps, given that I have an empty chunk
> of diskspace, to get Linux 2.6.12-rc3 to appear there, using
> git.

FWIW, excerpt from the README:

===

If you want to start out new project, do (IN NEW DIRECTORY)

        git init

and if you want to have a look at someone else's project, do

        git init URL

(your working directory will be by default tracking branch 'origin').

===

(although I'm not sure why did I write it when apparently noone bothers
to read it anyway ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.7

[Paul Jackson]

> (although I'm not sure why did I write it when apparently noone bothers
> to read it anyway ;-)

I read it - that's how I got the rest of the steps.

I did not recognize that what I wanted to do next was:

> and if you want to have a look at someone else's project, do
> 
>         git init URL

Good documentation is hard -- different people catch on to different
ways of saying the same thing at different times in different ways.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.7

[Junio C Hamano]

I was reviewing the differences in C-part between what is in
git-pasky and Linus tree.  By the way, I finally decided to look
at the upper layer again, now you switched to dircache based
implementation.  It looks like a good start.  Anyway, this
message is about purely C part.

First some nitpicks and possible bugs.

 - The remove_file_from_cache() function in read-cache.c was
   fixed for quite some time ago in the Linus tree to let users
   resolve unmerged path by "update-cache --remove".  You do not
   seem to have this part (the diff is reversed) [*R1*].  If this is
   not a merge oversight I'd like to know why?

 - show-diff exiting non-zero when unmatched paths are specified
   does not make much sense.  diff traditionally exits non-zero
   when differences are found.  Are you using this exit status
   to see if entries on the command line are in the dircache?
   If so that is not show-diff's job but probably belongs to
   show-files [*R2*].

Comments, commends and requests.

 - The -t option you have in show-files sounds generally
   useful [*R3*].  Could you push this upstream?

 - There are many small changes that adds free() and close(fd)
   and from my cursory looking they all look reasonable fixes.
   If you are confident with these, could please also push them
   upstream?

Thanks.

[References]

*R1*

This hunk should be reverted from Pasky if there is no good reason.

--- git.linus/read-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/read-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -99,9 +99,7 @@
 int remove_file_from_cache(char *path)
 {
 	int pos = cache_name_pos(path, strlen(path));
-	if (pos < 0)
-		pos = -pos-1;
-	while (pos < active_nr && !strcmp(active_cache[pos]->name, path))
+	if (pos >= 0)
 		remove_entry_at(pos);
 	return 0;
 }

*R2*

This hunk should be reverted from Pasky if there is no good reason.

--- git.linus/show-diff.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-diff.c	2005-04-24 00:49:00.000000000 -0700
@@ -126,6 +127,7 @@
 	int machine_readable = 0;
 	int reverse = 0;
 	int entries = read_cache();
+	int matched = 0;
 	int i;
 
 	while (1 < argc && argv[1][0] == '-') {
@@ -161,6 +163,7 @@
 		if (1 < argc &&
 		    ! matches_pathspec(ce, argv+1, argc-1))
 			continue;
+		matched++;
 
 		if (ce_stage(ce)) {
 			if (machine_readable)
@@ -192,10 +195,8 @@
 			continue;
 		if (!machine_readable)
 			printf("%s: %s\n", ce->name, sha1_to_hex(ce->sha1));
-		else {
-			printf("%s %s%c", sha1_to_hex(ce->sha1), ce->name, 0);
-			continue;
-		}
+		else
+			printf("M %s %s%c", sha1_to_hex(ce->sha1), ce->name, 0);
 		if (silent)
 			continue;
 
@@ -208,5 +209,8 @@
 					 reverse);
 		free(old);
 	}
+
+	if (1 < argc && !matched)
+		return 1;
 	return 0;
 }

*R3*

This should be pushed upstream.

--- git.linus/show-files.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-files.c	2005-04-24 00:49:00.000000000 -0700
@@ -17,6 +17,11 @@
 static int show_unmerged = 0;
 static int line_terminator = '\n';
 
+static const char *tag_cached = "";
+static const char *tag_unmerged = "";
+static const char *tag_removed = "";
+static const char *tag_other = "";
+
 static const char **dir;
 static int nr_dir;
 static int dir_alloc;
@@ -107,7 +112,7 @@
 	}
 	if (show_others) {
 		for (i = 0; i < nr_dir; i++)
-			printf("%s%c", dir[i], line_terminator);
+			printf("%s%s%c", tag_other, dir[i], line_terminator);
 	}
 	if (show_cached | show_stage) {
 		for (i = 0; i < active_nr; i++) {
@@ -115,10 +120,13 @@
 			if (show_unmerged && !ce_stage(ce))
 				continue;
 			if (!show_stage)
-				printf("%s%c", ce->name, line_terminator);
+				printf("%s%s%c",
+				       ce_stage(ce) ? tag_unmerged : tag_cached,
+				       ce->name, line_terminator);
 			else
 				printf(/* "%06o %s %d %10d %s%c", */
-				       "%06o %s %d %s%c",
+				       "%s %06o %s %d %s%c",
+				       ce_stage(ce) ? tag_unmerged : tag_cached,
 				       ntohl(ce->ce_mode),
 				       sha1_to_hex(ce->sha1),
 				       ce_stage(ce),
@@ -132,7 +140,7 @@
 			struct stat st;
 			if (!stat(ce->name, &st))
 				continue;
-			printf("%s%c", ce->name, line_terminator);
+			printf("%s%s%c", tag_removed, ce->name, line_terminator);
 		}
 	}
 	if (show_ignored) {
@@ -151,6 +159,13 @@
 			line_terminator = 0;
 			continue;
 		}
+		if (!strcmp(arg, "-t")) {
+			tag_cached = "H ";
+			tag_unmerged = "M ";
+			tag_removed = "R ";
+			tag_other = "? ";
+			continue;
+		}
 
 		if (!strcmp(arg, "--cached")) {
 			show_cached = 1;
@@ -179,7 +194,7 @@
 			continue;
 		}
 
-		usage("show-files [-z] (--[cached|deleted|others|ignored|stage])*");
+		usage("show-files [-z] [-t] (--[cached|deleted|others|ignored|stage])*");
 	}
 
 	/* With no flags, we default to showing the cached files */


*R4*

These leak fixes look reasonable from cursory looking.  If you
are confident, please push them upstream.

--- git.linus/checkout-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/checkout-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -48,6 +48,7 @@
 		buf[len] = 0;
 		mkdir(buf, 0755);
 	}
+	free(buf);
 }
 
 static int create_file(const char *path, unsigned int mode)
@@ -75,6 +76,8 @@
 
 	new = read_sha1_file(ce->sha1, type, &size);
 	if (!new || strcmp(type, "blob")) {
+		if (new)
+			free(new);
 		return error("checkout-cache: unable to read sha1 file of %s (%s)",
 			path, sha1_to_hex(ce->sha1));
 	}


--- git.linus/ls-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/ls-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -77,6 +77,7 @@
 	if (!buffer)
 		die("unable to read sha1 file");
 	list_recursive(buffer, "tree", size, NULL);
+	free(buffer);
 	return 0;
 }
 

--- git.linus/read-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/read-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -11,11 +11,14 @@
 {
 	void *buffer;
 	unsigned long size;
+	int ret;
 
 	buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
 	if (!buffer)
 		return -1;
-	return read_tree(buffer, size, stage);
+	ret = read_tree(buffer, size, stage);
+	free(buffer);
+	return ret;
 }
 
 static char *lockfile_name;


--- git.linus/rev-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/rev-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -56,10 +56,10 @@
 	struct commit_list *parents;
 	struct commit *obj = lookup_commit(sha1);
 
-	if (obj->object.parsed)
+	if (obj && obj->object.parsed)
 		return;
-
-	parse_commit(obj);
+	if (!obj || parse_commit(obj))
+		die("unable to parse commit (%s)", sha1_to_hex(sha1));
 	
 	parents = obj->parents;
 	while (parents) {


--- git.linus/show-diff.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-diff.c	2005-04-24 00:49:00.000000000 -0700
@@ -100,6 +100,7 @@
 		return;
 	}
 	show_differences("/dev/null", ce->name, old, size, reverse);
+	free(old);
 }
 
 static const char *show_diff_usage = "show-diff [-q] [-s] [-z] [paths...]";


* These all look genuine leak fixes.  If applicable to Linus tree please
  push them upstream.

--- git.linus/checkout-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/checkout-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -48,6 +48,7 @@
 		buf[len] = 0;
 		mkdir(buf, 0755);
 	}
+	free(buf);
 }
 
 static int create_file(const char *path, unsigned int mode)
@@ -75,6 +76,8 @@
 
 	new = read_sha1_file(ce->sha1, type, &size);
 	if (!new || strcmp(type, "blob")) {
+		if (new)
+			free(new);
 		return error("checkout-cache: unable to read sha1 file of %s (%s)",
 			path, sha1_to_hex(ce->sha1));
 	}


--- git.linus/ls-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/ls-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -77,6 +77,7 @@
 	if (!buffer)
 		die("unable to read sha1 file");
 	list_recursive(buffer, "tree", size, NULL);
+	free(buffer);
 	return 0;
 }
 
--- git.linus/read-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/read-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -11,11 +11,14 @@
 {
 	void *buffer;
 	unsigned long size;
+	int ret;
 
 	buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
 	if (!buffer)
 		return -1;
-	return read_tree(buffer, size, stage);
+	ret = read_tree(buffer, size, stage);
+	free(buffer);
+	return ret;
 }
 
 static char *lockfile_name;

--- git.linus/rev-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/rev-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -56,10 +56,10 @@
 	struct commit_list *parents;
 	struct commit *obj = lookup_commit(sha1);
 
-	if (obj->object.parsed)
+	if (obj && obj->object.parsed)
 		return;
-
-	parse_commit(obj);
+	if (!obj || parse_commit(obj))
+		die("unable to parse commit (%s)", sha1_to_hex(sha1));
 	
 	parents = obj->parents;
 	while (parents) {

--- git.linus/sha1_file.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/sha1_file.c	2005-04-24 00:49:00.000000000 -0700
@@ -278,6 +278,7 @@
 
 	if (write(fd, compressed, size) != size)
 		die("unable to write file");
+	free(compressed);
 	close(fd);
 		
 	return 0;
@@ -295,8 +296,10 @@
 	if (fd < 0)
 		return -1;
 
-	if (fstat(fd, &st) < 0 || size != st.st_size)
+	if (fstat(fd, &st) < 0 || size != st.st_size) {
+		close(fd);
 		return -1;
+	}
 
 	map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
 	close(fd);


--- git.linus/show-diff.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-diff.c	2005-04-24 00:49:00.000000000 -0700
@@ -100,6 +100,7 @@
 		return;
 	}
 	show_differences("/dev/null", ce->name, old, size, reverse);
+	free(old);
 }
 
 static const char *show_diff_usage = "show-diff [-q] [-s] [-z] [paths...]";


--- git.linus/update-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/update-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -104,6 +104,11 @@
 		close(fd);
 		return -1;
 	}
+	if (S_ISDIR(st.st_mode)) {
+		fprintf(stderr, "'%s' is a directory, ignoring\n", path);
+		close(fd);
+		return 0;
+	}
 	namelen = strlen(path);
 	size = cache_entry_size(namelen);
 	ce = malloc(size);
@@ -113,10 +118,15 @@
 	ce->ce_mode = create_ce_mode(st.st_mode);
 	ce->ce_flags = htons(namelen);
 
-	if (index_fd(ce->sha1, fd, &st) < 0)
+	if (index_fd(ce->sha1, fd, &st) < 0) {
+		free(ce);
 		return -1;
-
-	return add_cache_entry(ce, allow_add);
+	}
+	if (add_cache_entry(ce, allow_add)) {
+		free(ce);
+		return -1;
+	}
+	return 0;
 }
 
 static int match_data(int fd, void *buffer, unsigned long size)
@@ -141,7 +151,7 @@
 	if (fd >= 0) {
 		void *buffer;
 		unsigned long size;
-		char type[10];
+		char type[20];
 
 		buffer = read_sha1_file(ce->sha1, type, &size);
 		if (buffer) {
@@ -216,6 +226,9 @@
 			printf("%s: needs update\n", ce->name);
 			continue;
 		}
+		/* You can NOT just free active_cache[i] here, since it
+		 * might not be necessarily malloc()ed but can also come
+		 * from mmap(). */
 		active_cache[i] = new;
 	}
 }