threads / announce / 276

[ANNOUNCE] git-pasky-0.7

Subject: [ANNOUNCE] git-pasky-0.7

## tl;dr

17 messages between Apr 24, 2005 and Apr 24, 2005.

replies: 16people: 8as markdown or json

Petr Baudis· Apr 24, 2005, 00:59 UTC · lore
  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
Martin Schlemmer· Apr 24, 2005, 01:26 UTC · re: Petr Baudis · lore

Re: [ANNOUNCE] git-pasky-0.7

On Sun, 2005-04-24 at 02:59 +0200, Petr Baudis wrote:
Show 7 quoted lines
>   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
Linus Torvalds· Apr 24, 2005, 03:45 UTC · re: Martin Schlemmer · lore

Re: [ANNOUNCE] git-pasky-0.7

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
Martin Schlemmer· Apr 24, 2005, 09:50 UTC · re: Linus Torvalds · lore

Re: [ANNOUNCE] git-pasky-0.7

On Sat, 2005-04-23 at 20:45 -0700, Linus Torvalds wrote:
Show 9 quoted lines
> 
> 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
Paul Jackson· Apr 24, 2005, 03:58 UTC · re: Petr Baudis · lore

Re: [ANNOUNCE] git-pasky-0.7

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
Paul Jackson· Apr 24, 2005, 04:35 UTC · re: James Purser · lore

Re: [ANNOUNCE] git-pasky-0.7

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
Daniel Barkalow· Apr 24, 2005, 04:32 UTC · re: Paul Jackson · lore

Re: [ANNOUNCE] git-pasky-0.7

On Sat, 23 Apr 2005, Paul Jackson wrote:
Show 20 quoted lines
> 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*
Paul Jackson· Apr 24, 2005, 04:50 UTC · re: Daniel Barkalow · lore

Re: [ANNOUNCE] git-pasky-0.7

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
Paul Jackson· Apr 24, 2005, 05:02 UTC · re: Daniel Barkalow · lore

Re: [ANNOUNCE] git-pasky-0.7

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
Greg KH· Apr 24, 2005, 05:11 UTC · re: Paul Jackson · lore

Re: [ANNOUNCE] git-pasky-0.7

On Sat, Apr 23, 2005 at 10:02:36PM -0700, Paul Jackson wrote:
Show 11 quoted lines
> 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
Daniel Barkalow· Apr 24, 2005, 05:12 UTC · re: Paul Jackson · lore

Re: [ANNOUNCE] git-pasky-0.7

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*
Martin Schlemmer· Apr 24, 2005, 10:35 UTC · re: Paul Jackson · lore

Re: [ANNOUNCE] git-pasky-0.7

On Sat, 2005-04-23 at 22:02 -0700, Paul Jackson wrote:
Show 12 quoted lines
> 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
Petr Baudis· Apr 24, 2005, 07:14 UTC · re: Paul Jackson · lore

Re: [ANNOUNCE] git-pasky-0.7

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
Paul Jackson· Apr 24, 2005, 07:20 UTC · re: Petr Baudis · lore

Re: [ANNOUNCE] git-pasky-0.7

> (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
Junio C Hamano· Apr 24, 2005, 10:52 UTC · re: Petr Baudis · lore

Re: [ANNOUNCE] git-pasky-0.7

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;
 	}
 }

← back to recent threads