* Re: [PATCH] check for malloc
From: Linus Torvalds @ 2005-04-26 18:25 UTC (permalink / raw)
To: Christopher Li; +Cc: git mailing list
In-Reply-To: <20050426151217.GA5344@64m.dyndns.org>
On Tue, 26 Apr 2005, Christopher Li wrote:
>
> Add check for NULL return from malloc and realloc
I'd prefer xmalloc()/xrealloc() instead, and just do it in one place.
Linus
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Junio C Hamano @ 2005-04-26 18:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261103550.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Well, except for the fact that that isn't machine-readable
LT> either, since the "1 " thing might just be part of the
LT> filename..
Well, I somehow thought these things are in fixed column format;
mode, ->, sha, stage, and filename are all seperated with either
' ' or '\t'. So if I copy MN to "1 MN", presumably you would
see this:
100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 MN
100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 1 MN
So while I agree that // would also work, I fail to see why you
would even need that.
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> @ 2005-04-26 18:18 UTC (permalink / raw)
To: Matthias-Christian Ott, Linus Torvalds, git,
Linux Kernel Mailing List
In-Reply-To: <3XfpD-21C-11@gated-at.bofh.it>
Matthias-Christian Ott <matthias.christian@tiscali.de> wrote:
> And if you think "register" variables are outdated, please remove the
> CONFIG_REGPARM option from the Kernel source.
Register variables are outdated because they hinder the compiler from
optimizing by taking away 1/7 of the usable registers on x86. Use six
register variables and you're back to a accumulator-machine.
Use -O2 or -Os instead, the compiler is smarter than you.
The regparm calling convention will change the
load value -> store value on stack -> call sequence into
load value -> call -> store if needed
Obviously the second form can be better optimized than the first one.
Therefore it's a gain instead of a loss.
If you really want to help the compiler, look for something like repeated
pointer dereference or access to global variables and cache them in block-
local variables (pointers, int and uint only, even for caching chars).
Beware of volatile variables, and don't forget to look at the assembler code.
--
The generation of random numbers is too important to be left to chance.
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Chris Mason @ 2005-04-26 18:18 UTC (permalink / raw)
To: Magnus Damm; +Cc: Linus Torvalds, Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <aec7e5c305042609231a5d3f0@mail.gmail.com>
On Tuesday 26 April 2005 12:23, Magnus Damm wrote:
> Well, maybe I misunderstood everything, but I thought you were
> applying a lot of patches and complained that it took a lot of time
> due to the data order.
>
> When I applied a lot of patches to the kernel recently the cpu load
> dropped to zero after a while and the HD worked hard a sec or two and
> then things came back again. My primitive guess is that it was because
> the ext3 journal became full. To workaround this fact I started
> hacking on this in-memory patcher.
It looks like you'll only see the commits on ext3 when the log fills, and on
reiser3 you'll see it every 5 seconds or when the log fills. With the
default mount options, both ext3 and reiser will flush the data blocks at the
same time they are writing the metadata.
The easiest way to get around this is to mount -o data=writeback on
ext3/reiser, but you'll still have to wait for the data blocks eventually.
-chris
^ permalink raw reply
* Re: : Networking
From: Petr Baudis @ 2005-04-26 18:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Andrew Morton, David S. Miller, git
In-Reply-To: <Pine.LNX.4.21.0504261114090.30848-100000@iabervon.org>
Dear diary, on Tue, Apr 26, 2005 at 05:40:08PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Tue, 26 Apr 2005, Linus Torvalds wrote:
>
> > On Tue, 26 Apr 2005, Andrew Morton wrote:
> > >
> >
> > The only thing you should be a bit careful about is to remember what the
> > "heads" at different points were. In particular, you want to remember
> > where you merged with me last was. I've started tagging my releases with
> > the git tag facility (_not_ the pasky one, but I think pasky will start
> > picking up on that soon enough), so finding a specific release will be
> > easy, but if you ever do a non-release merge you'll just have to tag it
> > yourself.
>
> Your tag system is in the "cogito-0.8" release, plus a pasky-style way of
> keeping track of what tags you have in your repository.
It came in with merge with Linus, but there's no support in the Cogito
toolkit for it whatsoever.
I'm personally unlikely to get any time for doing it (or much anything
else; but this is probably the priority now) until Sunday evening. :-(
> > > d) To generate davem's tree (patch against linus's current tree (ie: patch
> > > against 2.6.12-rc3+linus.patch)):
> > >
> > > git pull git-net
> >
> > Yes. This should have merged the two (assuming "git pull" does what I
> > think it does).
>
> I think git pull only downloads the contents of the repo and saves the new
> head in a separate file. You're left to do the merge yourself, in case
> what you actually wanted to do was just read the patches in the remote
> repo without merging them.
>
> You probably need a "git merge git-net" here, and things will be in the
> state that Linus expects.
Yes. git pull only pulls the stuff, doesn't merge it (that is, unless it
is tracked branch; but I think this isn't the case; this was cleaned up
in cogito-0.8 and cg-pull now always only pulls, cg-update
pulls+merges).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: H. Peter Anvin @ 2005-04-26 18:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <Pine.LNX.4.58.0504252032500.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> And don't try to make me explain why the patchbomb has any IO time at all,
> it should all have fit in the cache, but I think the writeback logic
> kicked in.
The default log size on ext3 is quite small. Making the log larger
probably would have helped.
-hpa
^ permalink raw reply
* [PATCH] check for malloc
From: Christopher Li @ 2005-04-26 15:12 UTC (permalink / raw)
To: git mailing list; +Cc: Linus Torvalds
Add check for NULL return from malloc and realloc
Signed-off-by: Christopher Li <chrislgit@chrisli.org>
Index: git-hack/blob.c
===================================================================
--- git-hack.orig/blob.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/blob.c 2005-04-26 10:55:56.000000000 -0400
@@ -9,6 +9,8 @@
struct object *obj = lookup_object(sha1);
if (!obj) {
struct blob *ret = malloc(sizeof(struct blob));
+ if (!ret)
+ die("Out of memory, malloc failed");
memset(ret, 0, sizeof(struct blob));
created_object(sha1, &ret->object);
ret->object.type = blob_type;
Index: git-hack/checkout-cache.c
===================================================================
--- git-hack.orig/checkout-cache.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/checkout-cache.c 2005-04-26 10:56:32.000000000 -0400
@@ -42,6 +42,8 @@
char *buf = malloc(len + 1);
const char *slash = path;
+ if (!buf)
+ die ("Out of memory, malloc failed");
while ((slash = strchr(slash+1, '/')) != NULL) {
len = slash - path;
memcpy(buf, path, len);
Index: git-hack/commit-tree.c
===================================================================
--- git-hack.orig/commit-tree.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/commit-tree.c 2005-04-26 10:54:18.000000000 -0400
@@ -19,6 +19,8 @@
static void init_buffer(char **bufp, unsigned int *sizep)
{
char *buf = malloc(BLOCKING);
+ if (!buf)
+ die("Out of memory, malloc failed");
*sizep = 0;
*bufp = buf;
}
@@ -41,6 +43,8 @@
if (newsize > alloc) {
alloc = (newsize + 32767) & ~32767;
buf = realloc(buf, alloc);
+ if (!buf)
+ die("Out of memory, realloc failed");
*bufp = buf;
}
*sizep = newsize;
Index: git-hack/commit.c
===================================================================
--- git-hack.orig/commit.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/commit.c 2005-04-26 10:57:21.000000000 -0400
@@ -10,6 +10,8 @@
struct object *obj = lookup_object(sha1);
if (!obj) {
struct commit *ret = malloc(sizeof(struct commit));
+ if (!ret)
+ die("Out of memory, malloc failed");
memset(ret, 0, sizeof(struct commit));
created_object(sha1, &ret->object);
ret->object.type = commit_type;
@@ -79,6 +81,8 @@
void commit_list_insert(struct commit *item, struct commit_list **list_p)
{
struct commit_list *new_list = malloc(sizeof(struct commit_list));
+ if (new_list)
+ die("Out of memory, malloc failed");
new_list->item = item;
new_list->next = *list_p;
*list_p = new_list;
Index: git-hack/convert-cache.c
===================================================================
--- git-hack.orig/convert-cache.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/convert-cache.c 2005-04-26 10:58:51.000000000 -0400
@@ -20,6 +20,8 @@
{
struct entry *new = malloc(sizeof(struct entry));
+ if (!new)
+ die("Out of memory, malloc failed");
memset(new, 0, sizeof(*new));
memcpy(new->old_sha1, sha1, 20);
memmove(convert + pos + 1, convert + pos, (nr_convert - pos) * sizeof(struct entry *));
@@ -72,6 +74,8 @@
unsigned long newlen = 0;
unsigned long used;
+ if (!new)
+ die("Out of memory, malloc failed");
used = 0;
while (size) {
int len = 21 + strlen(buffer);
@@ -229,6 +233,8 @@
char *new = malloc(size + 100);
unsigned long newlen = 0;
+ if (!new)
+ die("Out of memory, malloc failed");
// "tree <sha1>\n"
memcpy(new + newlen, buffer, 46);
newlen += 46;
@@ -284,6 +290,8 @@
die("unable to read object %s", sha1_to_hex(sha1));
buffer = malloc(size);
+ if (!buffer)
+ die("Out of memory, malloc failed");
memcpy(buffer, data, size);
if (!strcmp(type, "blob")) {
Index: git-hack/diff-tree.c
===================================================================
--- git-hack.orig/diff-tree.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/diff-tree.c 2005-04-26 10:59:51.000000000 -0400
@@ -38,6 +38,8 @@
{
int baselen = strlen(base);
char *newbase = malloc(baselen + pathlen + 2);
+ if (!newbase)
+ die("Out of memory, malloc failed");
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, path, pathlen);
memcpy(newbase + baselen + pathlen, "/", 2);
@@ -271,6 +273,8 @@
paths = &argv[3];
nr_paths = argc - 3;
pathlens = malloc(nr_paths * sizeof(int));
+ if (!pathlens)
+ die("Out of memory, malloc failed");
for (i=0; i<nr_paths; i++)
pathlens[i] = strlen(paths[i]);
}
Index: git-hack/http-pull.c
===================================================================
--- git-hack.orig/http-pull.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/http-pull.c 2005-04-26 11:00:26.000000000 -0400
@@ -74,6 +74,8 @@
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
url = malloc(strlen(base) + 50);
+ if (!url)
+ die("Out of memory, malloc failed");
strcpy(url, base);
posn = url + strlen(base);
strcpy(posn, "objects/");
Index: git-hack/init-db.c
===================================================================
--- git-hack.orig/init-db.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/init-db.c 2005-04-26 11:00:43.000000000 -0400
@@ -35,6 +35,8 @@
}
len = strlen(sha1_dir);
path = malloc(len + 40);
+ if (!path)
+ die("Out of memory, malloc failed");
memcpy(path, sha1_dir, len);
safe_create_dir(sha1_dir);
Index: git-hack/object.c
===================================================================
--- git-hack.orig/object.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/object.c 2005-04-26 11:01:14.000000000 -0400
@@ -53,6 +53,8 @@
if (obj_allocs == nr_objs) {
obj_allocs = alloc_nr(obj_allocs);
objs = realloc(objs, obj_allocs * sizeof(struct object *));
+ if (!objs)
+ die("Out of memory, realloc failed");
}
/* Insert it into the right place */
@@ -76,6 +78,8 @@
target->used = 1;
p = malloc(sizeof(*p));
+ if (!p)
+ die("Out of memory, malloc failed");
p->item = target;
p->next = NULL;
*pp = p;
Index: git-hack/read-cache.c
===================================================================
--- git-hack.orig/read-cache.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/read-cache.c 2005-04-26 10:54:23.000000000 -0400
@@ -144,6 +144,8 @@
if (active_nr == active_alloc) {
active_alloc = alloc_nr(active_alloc);
active_cache = realloc(active_cache, active_alloc * sizeof(struct cache_entry *));
+ if (active_cache)
+ die("Out of memory, realloc failed");
}
/* Add it in.. */
Index: git-hack/sha1_file.c
===================================================================
--- git-hack.orig/sha1_file.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/sha1_file.c 2005-04-26 11:01:40.000000000 -0400
@@ -74,6 +74,8 @@
char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
int len = strlen(sha1_file_directory);
base = malloc(len + 60);
+ if (!base)
+ die("Out of memory, malloc failed");
memcpy(base, sha1_file_directory, len);
memset(base+len, 0, 60);
base[len] = '/';
@@ -272,6 +274,8 @@
deflateInit(&stream, Z_BEST_COMPRESSION);
size = deflateBound(&stream, len+hdrlen);
compressed = malloc(size);
+ if (!compressed)
+ die("Out of memory, malloc failed");
/* Compress it */
stream.next_out = compressed;
Index: git-hack/show-files.c
===================================================================
--- git-hack.orig/show-files.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/show-files.c 2005-04-26 10:54:23.000000000 -0400
@@ -31,8 +31,12 @@
if (nr_dir == dir_alloc) {
dir_alloc = alloc_nr(dir_alloc);
dir = realloc(dir, dir_alloc*sizeof(char *));
+ if (!dir)
+ die("Out of memory, realloc failed");
}
name = malloc(len + 1);
+ if (!name)
+ die("Out of memory, malloc failed");
memcpy(name, pathname, len + 1);
dir[nr_dir++] = name;
}
Index: git-hack/tree.c
===================================================================
--- git-hack.orig/tree.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/tree.c 2005-04-26 10:54:23.000000000 -0400
@@ -11,6 +11,8 @@
unsigned int size = cache_entry_size(baselen + len);
struct cache_entry *ce = malloc(size);
+ if (!ce)
+ die("Out of memory, malloc failed");
memset(ce, 0, size);
ce->ce_mode = create_ce_mode(mode);
@@ -44,6 +46,8 @@
char elttype[20];
unsigned long eltsize;
+ if (!newbase)
+ die("Out of memory, malloc failed");
eltbuf = read_sha1_file(sha1, elttype, &eltsize);
if (!eltbuf || strcmp(elttype, "tree"))
return -1;
@@ -75,6 +79,8 @@
struct object *obj = lookup_object(sha1);
if (!obj) {
struct tree *ret = malloc(sizeof(struct tree));
+ if (!ret)
+ die("Out of memory, malloc failed");
memset(ret, 0, sizeof(struct tree));
created_object(sha1, &ret->object);
ret->object.type = tree_type;
@@ -117,6 +123,8 @@
return -1;
entry = malloc(sizeof(struct tree_entry_list));
+ if (!entry)
+ die("Out of memory, malloc failed");
entry->name = strdup(path + 1);
entry->directory = S_ISDIR(mode);
entry->executable = mode & S_IXUSR;
Index: git-hack/update-cache.c
===================================================================
--- git-hack.orig/update-cache.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/update-cache.c 2005-04-26 11:02:27.000000000 -0400
@@ -41,6 +41,8 @@
void *in;
SHA_CTX c;
+ if (!metadata || !out)
+ die("Out of memory, malloc failed");
in = "";
if (size)
in = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
@@ -123,6 +125,8 @@
namelen = strlen(path);
size = cache_entry_size(namelen);
ce = malloc(size);
+ if (!ce)
+ die("Out of memory, malloc failed");
memset(ce, 0, size);
memcpy(ce->name, path, namelen);
fill_stat_cache_info(ce, &st);
@@ -206,6 +210,8 @@
size = ce_size(ce);
updated = malloc(size);
+ if (!updated)
+ die("Out of memory, malloc failed");
memcpy(updated, ce, size);
fill_stat_cache_info(updated, &st);
return updated;
@@ -282,6 +288,8 @@
len = strlen(arg3);
size = cache_entry_size(len);
ce = malloc(size);
+ if (!ce)
+ die("Out of memory, malloc failed");
memset(ce, 0, size);
memcpy(ce->sha1, sha1, 20);
Index: git-hack/write-tree.c
===================================================================
--- git-hack.orig/write-tree.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/write-tree.c 2005-04-26 10:54:23.000000000 -0400
@@ -27,6 +27,8 @@
/* Guess at some random initial size */
size = 8192;
buffer = malloc(size);
+ if (!buffer)
+ die("Out of memory, malloc failed");
offset = 0;
nr = 0;
@@ -69,6 +71,8 @@
if (offset + entrylen + 100 > size) {
size = alloc_nr(offset + entrylen + 100);
buffer = realloc(buffer, size);
+ if (!buffer)
+ die("Out of memory, realloc failed");
}
offset += sprintf(buffer + offset, "%o %.*s", mode, entrylen, filename);
buffer[offset++] = 0;
Index: git-hack/revision.h
===================================================================
--- git-hack.orig/revision.h 2005-04-26 10:52:38.000000000 -0400
+++ git-hack/revision.h 2005-04-26 11:05:24.000000000 -0400
@@ -69,9 +69,12 @@
if (rev_allocs == nr_revs) {
rev_allocs = alloc_nr(rev_allocs);
revs = realloc(revs, rev_allocs * sizeof(struct revision *));
+ if (!revs)
+ die("Out of memory, realloc failed")
}
n = malloc(sizeof(struct revision) + strlen(tag));
-
+ if (!n)
+ die("Out of memory, malloc failed");
n->flags = 0;
memcpy(n->sha1, sha1, 20);
n->parent = NULL;
@@ -97,6 +100,8 @@
}
p = malloc(sizeof(*p));
+ if (!p)
+ die("Out of memory, malloc failed");
p->parent = parent_rev;
p->next = NULL;
*pp = p;
Index: git-hack/diff.c
===================================================================
--- git-hack.orig/diff.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/diff.c 2005-04-26 11:00:06.000000000 -0400
@@ -103,6 +103,8 @@
char *cmd = malloc(cmd_size);
int next_at = 0;
+ if (!cmd)
+ die("Out of memory, malloc failed");
next_at += snprintf(cmd+next_at, cmd_size-next_at,
diff_cmd, name_sq, name_sq);
next_at += snprintf(cmd+next_at, cmd_size-next_at,
Index: git-hack/strbuf.c
===================================================================
--- git-hack.orig/strbuf.c 2005-04-26 10:52:47.000000000 -0400
+++ git-hack/strbuf.c 2005-04-26 10:54:23.000000000 -0400
@@ -1,6 +1,7 @@
#include <stdio.h>
#include <stdlib.h>
#include "strbuf.h"
+#include "cache.h"
void strbuf_init(struct strbuf *sb) {
sb->buf = 0;
@@ -16,6 +17,8 @@
if (sb->alloc <= sb->len) {
sb->alloc = sb->alloc * 3 / 2 + 16;
sb->buf = realloc(sb->buf, sb->alloc);
+ if (!sb->buf)
+ die("Out of memory, realloc failed");
}
sb->buf[sb->len++] = ch;
}
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Linus Torvalds @ 2005-04-26 18:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy8b5o211.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Apr 2005, Junio C Hamano wrote:
>
> While I agree with you that we should somehow show the stage, I
> do not like your suggestion above very much. How about adding
> one column for stage number before the filename when --unmerged
> is given, just like show-files --stage shows? You'd soon get
> used to the pattern that has a single digit in between
> whitespaces to recognize which is merged and which isn't.
Well, except for the fact that that isn't machine-readable either, since
the "1 " thing might just be part of the filename..
But you could use "/" to guarantee that it's unique, together with knowing
that git refuses to have non-canonical filenames.
Ie 1//filename.c _would_ be machine-readable, thanks to the "//" part,
which cannot be part of a valid canonical git filename.
Linus
^ permalink raw reply
* Re: [PATCH] Cogito chicken-and-egg problem
From: Daniel Barkalow @ 2005-04-26 17:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Petr Baudis
In-Reply-To: <1114534942.26856.10.camel@dv>
On Tue, 26 Apr 2005, Pavel Roskin wrote:
> > (Also, .git/HEAD is a dependancy, since you want to redo the version
> > script if you commit; but if you don't have it, that's okay and just means
> > you're building from a tarball, which is described completely by VERSION)
>
> It should be a conditional dependency, i.e. it should be a dependency
> if .git exists.
True.
> It seems to me that the whole idea of including SHA1 in cg-version is
> broken. SHA1 is not human readable. But if the maintainers insist on
> having SHA1 in cg-version, I want it to be done without causing build
> warnings for new users.
The idea is that it should appear if you're building a version that has
changes in its .git; in this case, VERSION is insufficient to tell you
which revision you have installed. If I've got cogito-0.8 + three untagged
commits from the remote repository + two local patches, I'd like to be
able to tell if the installed version is cogito-0.8 + two of the remote
patches. Possibly, it should also suppress the SHA1 if you've got a tagged
head, but identifying this situation is tricky, currently. Eventually, it
should be able to use a cg program to update VERSION from .git/HEAD and
include SHA1 for cases which aren't directly tagged.
> Here's an alternative patch.
I like your version.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Junio C Hamano @ 2005-04-26 17:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261005360.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I'm ok with that, but if so I think it should show the stage somehow, and
LT> make it clear that it's unmerged. Maybe by appending something to the name
LT> (maybe just a ':' and stage number, but I'd almost prefer the stage number
LT> to be translated into something human-readable, so maybe we could have
LT> something like
LT> filename.c^orig
LT> filename.c^first
LT> filename.c^second
LT> for stages 1-3 respectively)?
I'm the one who has been trying very hard to keep the output
machine readable (remember? many of the -z flags are mine).
While I agree with you that we should somehow show the stage, I
do not like your suggestion above very much. How about adding
one column for stage number before the filename when --unmerged
is given, just like show-files --stage shows? You'd soon get
used to the pattern that has a single digit in between
whitespaces to recognize which is merged and which isn't.
E.g. this is from show-files --stage:
100644 b258508afb7ceb449981bd9d63d2d3e971bf8d34 1 MM
100644 b431b272d829ff3aa4d1a5085f4394ab4d3305b6 2 MM
100644 19989d4559aae417fedee240ccf2ba315ea4dc2b 3 MM
100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 MN
Another thing I'd like to rectify is that show-files use a space
while diff-tree and friends use a tab in between columns. Is it
too late to standardize one way or the other? My vote goes to
a space.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.8 (former git-pasky, big changes!)
From: Paul Jackson @ 2005-04-26 17:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: mike.taht, git
In-Reply-To: <20050426122304.GD18971@pasky.ji.cz>
> some way to deal with renames sensibly.
For a Linux kernel merge tool that I did inside SGI, I come to the
conclusion the following heuristics identified renames fairly
accurately, coming up with the same renames as a careful manual
examination.
The key heuristic was to consider one file A to be a rename of another B
if the size (number of lines) of the diff of A and B (diff -auw A B | wc
-l) is less than 50% of the combined size of A and B (cat A B | wc -l).
Only pathname pairs with the same basename were considered - I was
focused here on renames due to directory restructuring. I'm not sure
now if this is a good assumption - but it sure saved some computation.
Any file with the string "Makefile" in its name had to be excluded from
consideration.
In case of multiple potential renames (say one file is copied to two
places, removing the original and modifying each copy a little), the
'best' rename was selected, where 'best' meant the lowest ratio of
diff 'diff -auw' size to combined 'cat' size.
The end result of the above was a fairly natural identification of
renames. If say I moved kernel/cpuset.c to mm/cpuset.c and changed
it a little bit, the above heuristics would show a rename, plus
a few changes.
--
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
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Chris Mason @ 2005-04-26 17:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <Pine.LNX.4.58.0504260939440.18901@ppc970.osdl.org>
On Tuesday 26 April 2005 12:42, Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Chris Mason wrote:
> > This agrees with my tests here, the time to apply patches is somewhat
> > disk bound, even for the small 100 or 200 patch series. The io should be
> > coming from data=ordered, since the commits are still every 5 seconds or
> > so.
>
> Yes, ext3 really does suck in many ways.
>
> One of my (least) favourite suckage is a process that does "fsync" on a
> single file (mail readers etc), which apparently causes ext3 to sync all
> dirty data, because it can only sync the whole log. So if you have stuff
> that writes out things that aren't critical, it negatively affects
> something totally independent that _does_ care.
>
> I remember some early stuff showing that reiserfs was _much_ better for
> BK. I'd be willing to bet that's probably true for git too.
reiserfs shares the same basic data=ordered idea as ext3, so the fsync will do
the same on reiser as it does on ext3. I do have code in there to try and
keep the data=ordered writeback a little less bursty than it is in ext3 so
you might not notice the fsync as much.
I haven't compared reiser vs ext3 for git. reiser tails should help
performance because once you read the object inode you've also got the data.
But, I would expect the biggest help to come from mounting reiserfs -o
alloc=skip_busy. This basically allocates all new files one right after the
other on disk regardless of which subdir they are in. The effect is to time
order most of your files.
As an example, here's the time to apply 300 patches on ext3. This was with my
packed patches applied, but vanilla git should show similar percentage
differences.
data=writeback 32s
data=ordered 44s
With a long enough test, data=ordered should fall into the noise, but 10-40
second runs really show it.
-chris
^ permalink raw reply
* Re: (SOLVED) Re: cg-add and update-cache add fails
From: Daniel Barkalow @ 2005-04-26 17:51 UTC (permalink / raw)
To: Rhys Hardwick; +Cc: git
In-Reply-To: <200504261744.44394.rhys@rhyshardwick.co.uk>
On Tue, 26 Apr 2005, Rhys Hardwick wrote:
> Ok, I have been known to be silly. But this silly? :)
>
> Create the file, then add it to the repository. Makes sense really.
You might do well to send in a patch that gives a useful error message,
like "something.c: File not found", since other people have been known to
be silly, too.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: : Networking
From: Jan Harkes @ 2005-04-26 17:19 UTC (permalink / raw)
To: git
In-Reply-To: <20050426005725.6bfe6135.akpm@osdl.org>
Forgot to cc: git@vger when I sent this originally.
On Tue, Apr 26, 2005 at 12:57:25AM -0700, Andrew Morton wrote:
> 27 files changed, 46 insertions(+), 80 deletions(-)
>
> And that's the bad patch.
Both Linus and DaveM merged the same patch from Al Viro, but they are
ofcourse different commits. So both branches have diverged and would
need to be merged, where someone decides if Linus's commit or Dave's
commit should be used.
> What did I do wrong?
>
> Can someone suggest a better approach?
Well, I looked at the history, and if I skip the Viro patch in davem's
branch by hand I get,
$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:088dd3a45fdb8fb726cd50575856562c4f6f1c3e | diffstat
drivers/net/tg3.c | 73 ++++++++++++++-------------
net/ipv4/ip_output.c | 2
net/ipv4/netfilter/ip_conntrack_ftp.c | 4 -
net/ipv4/netfilter/ip_conntrack_standalone.c | 7 --
net/ipv4/tcp_input.c | 1
net/sched/simple.c | 18 ------
6 files changed, 46 insertions(+), 59 deletions(-)
So now, how to do this without picking through the logs. I figured the
patchutils stuff might have a solution for this. So I got the diffs on
Linus's branch wrt to the gca, and from Dave's branch wrt to the gca.
$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:b453257f057b834fdf9f4a6ad6133598b79bd982 > git-linus.patch
$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:5523662c4cd585b892811d7bb3e25d9a787e19b3 > git-net.patch
$ interdiff --no-revert-omitted -p1 git-linus.patch git-net.patch | diffstat
drivers/net/tg3.c | 73 ++++++++++++++-------------
net/ipv4/ip_output.c | 2
net/ipv4/netfilter/ip_conntrack_ftp.c | 4 -
net/ipv4/netfilter/ip_conntrack_standalone.c | 7 --
net/ipv4/tcp_input.c | 1
net/sched/simple.c | 18 ------
6 files changed, 46 insertions(+), 59 deletions(-)
That looks like it matched.
Jan
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Linus Torvalds @ 2005-04-26 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jippjky.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Apr 2005, Junio C Hamano wrote:
>
> The patch lets you have it in both ways by adding --unmerged
> flag. Without it, unmerged entries are culled at the beginning;
> with it, you will see diffs for all unmerged stages.
I'm ok with that, but if so I think it should show the stage somehow, and
make it clear that it's unmerged. Maybe by appending something to the name
(maybe just a ':' and stage number, but I'd almost prefer the stage number
to be translated into something human-readable, so maybe we could have
something like
filename.c^orig
filename.c^first
filename.c^second
for stages 1-3 respectively)?
I'll apply your fix right now.
Linus
^ permalink raw reply
* Re: [PATCH] Cogito chicken-and-egg problem
From: Pavel Roskin @ 2005-04-26 17:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504261229220.30848-100000@iabervon.org>
Hello, Daniel!
On Tue, 2005-04-26 at 12:38 -0400, Daniel Barkalow wrote:
> > Also, the dependency on commit-id was dropped from my patch for some
> > reason. I believe it's still needed. Also, we need a dependency on
> > cat-file, which is used by commit-id internally.
>
> commit-id doesn't really use cat-file; the way it calls gitXnormid.sh
There is gitXnormid.sh in the current cogito. Please update your tree.
> definitely suppresses that section.
That's not what I see if I remove cat-file but leave commit-id in my
$HOME/bin:
proski@dv:~/src/cogito$ make cg-version
/home/proski/bin/commit-id: line 35: cat-file: command not found
Invalid id: f9f0459b5b39cf83143c91ae39b4eaf187cf678a
Generating cg-version...
proski@dv:~/src/cogito$
> In fact, commit-id with no arguments
> is simply an easy-to-remember way of doing "cat .git/HEAD" using a much
> more complicated script. Earlier, I sent a patch to just do this, since it
> avoids the whole issue.
That would be fine with me.
> (Also, .git/HEAD is a dependancy, since you want to redo the version
> script if you commit; but if you don't have it, that's okay and just means
> you're building from a tarball, which is described completely by VERSION)
It should be a conditional dependency, i.e. it should be a dependency
if .git exists.
It seems to me that the whole idea of including SHA1 in cg-version is
broken. SHA1 is not human readable. But if the maintainers insist on
having SHA1 in cg-version, I want it to be done without causing build
warnings for new users.
Here's an alternative patch.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Index: Makefile
===================================================================
--- f262000f302b749e485f5eb971e6aabefbb85680/Makefile (mode:100644 sha1:4f01bbbbb3fd0e53e9ce968f167b6dae68fcfa92)
+++ uncommitted/Makefile (mode:100644)
@@ -87,12 +87,21 @@
http-pull: LIBS += -lcurl
+ifneq (,$(wildcard .git))
+cg-version: $(VERSION) .git/HEAD
+ @echo Generating cg-version...
+ @rm -f $@
+ @echo "#!/bin/sh" > $@
+ @echo "echo \"$(shell cat $(VERSION)) ($(shell cat .git/HEAD))\"" >> $@
+ @chmod +x $@
+else
cg-version: $(VERSION)
@echo Generating cg-version...
@rm -f $@
@echo "#!/bin/sh" > $@
- @PATH=.:$(PATH) echo "echo \"$(shell cat $(VERSION)) ($(shell commit-id))\"" >> $@
+ @echo "echo \"$(shell cat $(VERSION))\"" >> $@
@chmod +x $@
+endif
install: $(PROG) $(SCRIPTS) $(SCRIPT) $(GEN_SCRIPT)
install -m755 -d $(DESTDIR)$(bindir)
--
Regards,
Pavel Roskin
^ permalink raw reply
* [RFC] diff-cache buglet
From: Junio C Hamano @ 2005-04-26 16:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus,
what do you want diff-cache to do upon finding an
unmerged path? Currently your code says "undecided" to me.
The main() attempts to first remove all merge entries before
letting the diff_cache() do its work, but the diff_cache()
itself has also some code to deal with unmerged entries.
In the attached patch, the second hunk starting at ll 76 is a
pure and obvious bugfix. The function is attempting to remove
all merge entries, but it stops in the middle; that's why I said
"attempts" in the above.
The patch lets you have it in both ways by adding --unmerged
flag. Without it, unmerged entries are culled at the beginning;
with it, you will see diffs for all unmerged stages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
jit-snap -v 0
--- k/diff-cache.c
+++ l/diff-cache.c
@@ -1,5 +1,6 @@
#include "cache.h"
+static int leave_unmerged = 0;
static int cached_only = 0;
static int line_termination = '\n';
@@ -76,7 +77,7 @@ static void remove_merge_entries(void)
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (!ce_stage(ce))
- break;
+ continue;
printf("%s: unmerged\n", ce->name);
while (remove_entry_at(i)) {
if (!ce_stage(active_cache[i]))
@@ -85,7 +86,8 @@ static void remove_merge_entries(void)
}
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static char *diff_cache_usage =
+"diff-cache [-r] [-z] [--cached] [--unmerged] <tree sha1>";
int main(int argc, char **argv)
{
@@ -110,13 +112,18 @@ int main(int argc, char **argv)
cached_only = 1;
continue;
}
+ if (!strcmp(arg, "--unmerged")) {
+ leave_unmerged = 1;
+ continue;
+ }
usage(diff_cache_usage);
}
if (argc != 2 || get_sha1_hex(argv[1], tree_sha1))
usage(diff_cache_usage);
- remove_merge_entries();
+ if (!leave_unmerged)
+ remove_merge_entries();
tree = read_tree_with_tree_or_commit_sha1(tree_sha1, &size, 0);
if (!tree)
^ permalink raw reply
* Re: [PATCH] Cogito chicken-and-egg problem
From: Daniel Barkalow @ 2005-04-26 16:38 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1114531570.19478.6.camel@dv>
On Tue, 26 Apr 2005, Pavel Roskin wrote:
> Hello!
>
> My patch for Makefile was misapplied, so installed commit-id is still
> needed for "make" to succeed.
>
> Shell commands are processed by make before being passed to the shell,
> and $(...) is expanded by make before new PATH is set, as it is done in
> the current Makefile.
>
> Also, the dependency on commit-id was dropped from my patch for some
> reason. I believe it's still needed. Also, we need a dependency on
> cat-file, which is used by commit-id internally.
commit-id doesn't really use cat-file; the way it calls gitXnormid.sh
definitely suppresses that section. In fact, commit-id with no arguments
is simply an easy-to-remember way of doing "cat .git/HEAD" using a much
more complicated script. Earlier, I sent a patch to just do this, since it
avoids the whole issue.
(Also, .git/HEAD is a dependancy, since you want to redo the version
script if you commit; but if you don't have it, that's okay and just means
you're building from a tarball, which is described completely by VERSION)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* (SOLVED) Re: cg-add and update-cache add fails
From: Rhys Hardwick @ 2005-04-26 16:44 UTC (permalink / raw)
To: git
In-Reply-To: <200504261735.47008.rhys@rhyshardwick.co.uk>
Ok, I have been known to be silly. But this silly? :)
Create the file, then add it to the repository. Makes sense really.
Rhys
On Tuesday 26 Apr 2005 17:35, Rhys Hardwick wrote:
> Hey there,
>
> I posted a little while ago about this, but thought I would collate all my
> findings. I am very lost. Trying to add files to the repository does not
> seem to work, no matter which git repository I try. Creating new trees and
> updating current trees, as well as removing files is not a problem. All
> other areas of git seem to work perfectly. I am currently using
> cogito-0.8. This error started to occur in pasky-0.63.
>
> Here is the error I get:
>
> rhys@metatron:~/repo/learning.repo$ cg-add w1p4d1.c
> fatal: Unable to add w1p4d1.c to database
> rhys@metatron:~/repo/learning.repo$ update-cache --add w1p4d1.c
> fatal: Unable to add w1p4d1.c to database
>
> All the files under the .git folder appear to be owned by me, and are
> read-writable. The disk is not full.
>
> I have attached the output from strace and ltrace.
>
> If anyone could shed any light on why this might be happening, I would be
> very grateful.
>
> Rhys
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Linus Torvalds @ 2005-04-26 16:42 UTC (permalink / raw)
To: Chris Mason; +Cc: Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <200504260713.26020.mason@suse.com>
On Tue, 26 Apr 2005, Chris Mason wrote:
>
> This agrees with my tests here, the time to apply patches is somewhat disk
> bound, even for the small 100 or 200 patch series. The io should be coming
> from data=ordered, since the commits are still every 5 seconds or so.
Yes, ext3 really does suck in many ways.
One of my (least) favourite suckage is a process that does "fsync" on a
single file (mail readers etc), which apparently causes ext3 to sync all
dirty data, because it can only sync the whole log. So if you have stuff
that writes out things that aren't critical, it negatively affects
something totally independent that _does_ care.
I remember some early stuff showing that reiserfs was _much_ better for
BK. I'd be willing to bet that's probably true for git too.
Linus
^ permalink raw reply
* cg-add and update-cache add fails
From: Rhys Hardwick @ 2005-04-26 16:35 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
Hey there,
I posted a little while ago about this, but thought I would collate all my
findings. I am very lost. Trying to add files to the repository does not
seem to work, no matter which git repository I try. Creating new trees and
updating current trees, as well as removing files is not a problem. All
other areas of git seem to work perfectly. I am currently using cogito-0.8.
This error started to occur in pasky-0.63.
Here is the error I get:
rhys@metatron:~/repo/learning.repo$ cg-add w1p4d1.c
fatal: Unable to add w1p4d1.c to database
rhys@metatron:~/repo/learning.repo$ update-cache --add w1p4d1.c
fatal: Unable to add w1p4d1.c to database
All the files under the .git folder appear to be owned by me, and are
read-writable. The disk is not full.
I have attached the output from strace and ltrace.
If anyone could shed any light on why this might be happening, I would be very
grateful.
Rhys
[-- Attachment #2: strace and ltrace --]
[-- Type: text/plain, Size: 20437 bytes --]
rhys@metatron:~/repo/learning.repo$ strace cg-add w1d4p1.c
execve("/home/rhys/bin/cg-add", ["cg-add", "w1d4p1.c"], [/* 37 vars */]) = 0
uname({sys="Linux", node="metatron", ...}) = 0
brk(0) = 0x804c000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe9000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78602, ...}) = 0
old_mmap(NULL, 78602, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd5000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7ea0000
old_mmap(0xb7fca000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x129000) = 0xb7fca000
old_mmap(0xb7fd3000, 7308, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd3000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e9f000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e9f460, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7fd5000, 78602) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=290448, ...}) = 0
mmap2(NULL, 290448, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e58000
close(3) = 0
brk(0) = 0x804c000
brk(0x806d000) = 0x806d000
brk(0) = 0x806d000
execve("/usr/local/bin/bash", ["bash", "/home/rhys/bin/cg-add", "w1d4p1.c"], [/* 37 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/bin/bash", ["bash", "/home/rhys/bin/cg-add", "w1d4p1.c"], [/* 37 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/bash", ["bash", "/home/rhys/bin/cg-add", "w1d4p1.c"], [/* 37 vars */]) = 0
uname({sys="Linux", node="metatron", ...}) = 0
brk(0) = 0x80f1000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe9000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78602, ...}) = 0
old_mmap(NULL, 78602, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd5000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\342"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=252592, ...}) = 0
old_mmap(NULL, 257868, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7f96000
old_mmap(0xb7fcc000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x35000) = 0xb7fcc000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\32"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9872, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f95000
old_mmap(NULL, 8632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7f92000
old_mmap(0xb7f94000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0xb7f94000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7e5d000
old_mmap(0xb7f87000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x129000) = 0xb7f87000
old_mmap(0xb7f90000, 7308, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f90000
close(3) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f95b80, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7fd5000, 78602) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
close(3) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=290448, ...}) = 0
mmap2(NULL, 290448, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e16000
close(3) = 0
brk(0) = 0x80f1000
brk(0) = 0x80f1000
brk(0x80f2000) = 0x80f2000
brk(0) = 0x80f2000
brk(0x80f3000) = 0x80f3000
brk(0) = 0x80f3000
brk(0x80f4000) = 0x80f4000
getuid32() = 1000
getgid32() = 1000
geteuid32() = 1000
getegid32() = 1000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
time(NULL) = 1114533106
brk(0) = 0x80f4000
brk(0x80f5000) = 0x80f5000
open("/etc/mtab", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=381, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e15000
read(3, "/dev/hda7 / ext3 rw,errors=remou"..., 4096) = 381
close(3) = 0
munmap(0xb7e15000, 4096) = 0
open("/proc/meminfo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e15000
read(3, "MemTotal: 906680 kB\nMemFre"..., 1024) = 598
close(3) = 0
munmap(0xb7e15000, 4096) = 0
brk(0) = 0x80f5000
brk(0x80f6000) = 0x80f6000
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
uname({sys="Linux", node="metatron", ...}) = 0
brk(0) = 0x80f6000
brk(0x80f7000) = 0x80f7000
stat64("/home/rhys/repo/learning.repo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getpid() = 9873
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
brk(0) = 0x80f7000
brk(0x80f8000) = 0x80f8000
open("/usr/lib/gconv/gconv-modules", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=45278, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e15000
read(3, "# GNU libc iconv configuration.\n"..., 4096) = 4096
brk(0) = 0x80f8000
brk(0x80f9000) = 0x80f9000
read(3, ".B1.002//\nalias\tJS//\t\t\tJUS_I.B1."..., 4096) = 4096
brk(0) = 0x80f9000
brk(0x80fa000) = 0x80fa000
brk(0) = 0x80fa000
brk(0x80fb000) = 0x80fb000
brk(0) = 0x80fb000
brk(0x80fc000) = 0x80fc000
read(3, "859-3\t1\nmodule\tINTERNAL\t\tISO-885"..., 4096) = 4096
brk(0) = 0x80fc000
brk(0x80fd000) = 0x80fd000
brk(0) = 0x80fd000
brk(0x80fe000) = 0x80fe000
brk(0) = 0x80fe000
brk(0x80ff000) = 0x80ff000
read(3, "9-14//\nalias\tLATIN8//\t\tISO-8859-"..., 4096) = 4096
brk(0) = 0x80ff000
brk(0x8100000) = 0x8100000
brk(0) = 0x8100000
brk(0x8101000) = 0x8101000
brk(0) = 0x8101000
brk(0x8102000) = 0x8102000
read(3, "CSEBCDICES//\t\tEBCDIC-ES//\nalias\t"..., 4096) = 4096
brk(0) = 0x8102000
brk(0x8103000) = 0x8103000
brk(0) = 0x8103000
brk(0x8104000) = 0x8104000
read(3, "IBM284//\nalias\tEBCDIC-CP-ES//\t\tI"..., 4096) = 4096
brk(0) = 0x8104000
brk(0x8105000) = 0x8105000
brk(0) = 0x8105000
brk(0x8106000) = 0x8106000
brk(0) = 0x8106000
brk(0x8107000) = 0x8107000
read(3, "ias\t864//\t\t\tIBM864//\nalias\tCSIBM"..., 4096) = 4096
brk(0) = 0x8107000
brk(0x8108000) = 0x8108000
brk(0) = 0x8108000
brk(0x8109000) = 0x8109000
brk(0) = 0x8109000
brk(0x810a000) = 0x810a000
read(3, "\tIBM937\t\t1\nmodule\tINTERNAL\t\tIBM9"..., 4096) = 4096
brk(0) = 0x810a000
brk(0x810b000) = 0x810b000
brk(0) = 0x810b000
brk(0x810c000) = 0x810c000
brk(0) = 0x810c000
brk(0x810d000) = 0x810d000
read(3, "UC-JP//\nmodule\tEUC-JP//\t\tINTERNA"..., 4096) = 4096
brk(0) = 0x810d000
brk(0x810e000) = 0x810e000
brk(0) = 0x810e000
brk(0x810f000) = 0x810f000
brk(0) = 0x810f000
brk(0x8110000) = 0x8110000
read(3, "143IECP271//\tIEC_P27-1//\nalias\tI"..., 4096) = 4096
brk(0) = 0x8110000
brk(0x8111000) = 0x8111000
brk(0) = 0x8111000
brk(0x8112000) = 0x8112000
read(3, "\nmodule\tINTERNAL\t\tISO_10367-BOX/"..., 4096) = 4096
brk(0) = 0x8112000
brk(0x8113000) = 0x8113000
brk(0) = 0x8113000
brk(0x8114000) = 0x8114000
brk(0) = 0x8114000
brk(0x8115000) = 0x8115000
read(3, "\t\tto\t\t\tmodule\t\tcost\nmodule\tShift"..., 4096) = 222
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7e15000, 4096) = 0
brk(0) = 0x8115000
brk(0x8116000) = 0x8116000
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\6\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=5920, ...}) = 0
brk(0) = 0x8116000
brk(0x8117000) = 0x8117000
old_mmap(NULL, 8860, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7e13000
old_mmap(0xb7e15000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0xb7e15000
close(3) = 0
getppid() = 9872
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/local/bin/bash", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/bash", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=667180, ...}) = 0
getgroups32(32, [20, 24, 25, 29, 33, 44, 1000]) = 7
stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=667180, ...}) = 0
getpgrp() = 9872
rt_sigaction(SIGCHLD, {0x807ac80, [], 0}, {SIG_DFL}, 8) = 0
brk(0) = 0x8117000
brk(0x8118000) = 0x8118000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/home/rhys/bin/cg-add", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff608) = -1 ENOTTY (Inappropriate ioctl for device)
_llseek(3, 0, [0], SEEK_CUR) = 0
read(3, "#!/usr/bin/env bash\n#\n# Add new "..., 80) = 80
_llseek(3, 0, [0], SEEK_SET) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
dup2(3, 255) = 255
close(3) = 0
fcntl64(255, F_SETFD, FD_CLOEXEC) = 0
fcntl64(255, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(255, {st_mode=S_IFREG|0755, st_size=300, ...}) = 0
_llseek(255, 0, [0], SEEK_CUR) = 0
brk(0) = 0x8118000
brk(0x8119000) = 0x8119000
brk(0) = 0x8119000
brk(0x811a000) = 0x811a000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, "#!/usr/bin/env bash\n#\n# Add new "..., 300) = 300
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/local/bin/cg-Xlib", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/cg-Xlib", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/bin/cg-Xlib", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/X11/cg-Xlib", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/games/cg-Xlib", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/home/rhys/bin/cg-Xlib", {st_mode=S_IFREG|0755, st_size=835, ...}) = 0
stat64("/home/rhys/bin/cg-Xlib", {st_mode=S_IFREG|0755, st_size=835, ...}) = 0
open("/home/rhys/bin/cg-Xlib", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=835, ...}) = 0
read(3, "#!/usr/bin/env bash\n#\n# Common c"..., 835) = 835
close(3) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
brk(0) = 0x811a000
brk(0x811b000) = 0x811b000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".git/remotes", 0xbffff070) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".git/refs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/local/bin/update-cache", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/update-cache", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/bin/update-cache", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/X11/update-cache", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/usr/games/update-cache", 0xbffff490) = -1 ENOENT (No such file or directory)
stat64("/home/rhys/bin/update-cache", {st_mode=S_IFREG|0755, st_size=91464, ...}) = 0
stat64("/home/rhys/bin/update-cache", {st_mode=S_IFREG|0755, st_size=91464, ...}) = 0
brk(0) = 0x811b000
brk(0x811c000) = 0x811c000
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
clone(fatal: Unable to add w1d4p1.c to database
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f95bc8) = 9874
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], WNOHANG) = 9874
waitpid(-1, 0xbffff164, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x8079bd0, [], 0}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {0x8079bd0, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, "", 300) = 0
exit_group(1) = ?
========================================================================================
rhys@metatron:~/repo/learning.repo$ ltrace update-cache --add w1d4p1.c
__libc_start_main(0x80496b0, 3, 0xbffff854, 0x804ae20, 0x804ae80 <unfinished ...>
getenv("GIT_INDEX_FILE") = NULL
snprintf(".git/index.lock", 4097, "%s.lock", ".git/index") = 15
open(".git/index.lock", 194, 0600) = 3
__cxa_atexit(0x8049690, 0, 0, 0xb7f8de80, 0xbffff7c8) = 0
__errno_location() = 0xb7d59280
getenv("SHA1_FILE_DIRECTORY") = NULL
access(".git/objects", 1) = 0
getenv("GIT_INDEX_FILE") = NULL
open(".git/index", 0, 026777021220) = 4
__fxstat(3, 4, 0xbffff710) = 0
__errno_location() = 0xb7d59280
mmap(0, 176, 1, 2, 4) = 0xb7fe8000
close(4) = 0
SHA1_Init(0xbffff660, 0xb7e67bc8, 0xb7fc2290, 0x804870e, 96) = 1
SHA1_Update(0xbffff660, 0xb7fe8000, 156, 0x804870e, 96) = 1
SHA1_Final(0xbffff640, 0xbffff660, 156, 0x804870e, 96) = 1
calloc(27, 4) = 0x8050008
open("w1d4p1.c", 0, 044653) = -1
__errno_location() = 0xb7d59280
fputs("fatal: ", 0xb7f86f60fatal: ) = 1
vfprintf(0xb7f86f60, "Unable to add %s to database", 0xbffff794Unable to add w1d4p1.c to database) = 34
fputc('\n', 0xb7f86f60
) = 10
exit(1 <unfinished ...>
unlink(".git/index.lock") = 0
+++ exited (status 1) +++
rhys@metatron:~/repo/learning.repo$
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Magnus Damm @ 2005-04-26 16:23 UTC (permalink / raw)
To: Chris Mason; +Cc: Linus Torvalds, Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <200504261138.46339.mason@suse.com>
On 4/26/05, Chris Mason <mason@suse.com> wrote:
> On Tuesday 26 April 2005 11:09, Magnus Damm wrote:
> > On 4/26/05, Chris Mason <mason@suse.com> wrote:
> > > This agrees with my tests here, the time to apply patches is somewhat
> > > disk bound, even for the small 100 or 200 patch series. The io should be
> > > coming from data=ordered, since the commits are still every 5 seconds or
> > > so.
> >
> > Yes, as long as you apply the patches to disk that is. I've hacked up
> > a small backend tool that applies patches to files kept in memory and
> > uses a modifed rabin-karp search to match hunks. So you basically read
> > once and write once per file instead of moving data around for each
> > applied patch. But it needs two passes.
> >
> > And no, the source code for the entire Linux kernel is not kept in
> > memory - you need a smart frontend to manage the file cache. Drop me a
> > line if you are interested.
>
> Sorry, you've lost me. Right now the cycle goes like this:
Ehrm, maybe I'm way off. =)
> 1) patch reads patch file, reads source file, writes source file
> 2) update-cache reads source file, writes git file
Ok.
> Which of those writes are you avoiding? We have a smart way to manage the
> cache already for the source files...the vm does pretty well. There's
> nothing to manage for the git files. For the apply a bunch of patches
> workload, they are write once, read never (except for the index).
Well, maybe I misunderstood everything, but I thought you were
applying a lot of patches and complained that it took a lot of time
due to the data order.
When I applied a lot of patches to the kernel recently the cpu load
dropped to zero after a while and the HD worked hard a sec or two and
then things came back again. My primitive guess is that it was because
the ext3 journal became full. To workaround this fact I started
hacking on this in-memory patcher.
In the cycle above, I'm trying to speed up step 1:
If the patch modifies each source file multiple times (either using
multiple hunks or multiple ---/+++) then the lines below the hunk in
the source file will be moved multiple times. And if the source file
is written to disk after each hunk or ---/+++ is applied then this
will generate a lot of writes that can be avoided if the entire patch
procedure is broken down into a first pass that analyzes the patches
and a second pass that applies the patches and keeps source files in
memory.
But my rather trivial observation above is of course only suitable if
you have a lot of patches that should be applied and you are only
interested in the final version of the patched source files. If you
apply one patch at a time and import each source file as a new
revision then my little hack is probably not for you.
/ magnus
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Bill Davidsen @ 2005-04-26 16:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <Pine.LNX.4.58.0504251938210.18901@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
Linus Torvalds wrote:
>
> On Mon, 25 Apr 2005, Mike Taht wrote:
>
>>One difference is probably - mercurial appears to be using zlib's
>>*default* compression of 6....
>>
>>using zlib compression of 9 really impacts git...
>
>
> I agree that it will hurt for big changes, but since I really do believe
> that most changes are just a couple of files, I don't believe it matters
> for those.
>
> I forget what the exact numbers were, but I did some timings on plain
> "gzip", and it basically said that doing gzip on a medium-sized file was
> not that different for -6 and -9. Why? Because most of the overhead was
> elsewhere ;)
Certainly not different in the overall numbers, but after trying gzip on
a bunch of various source files on 32 bit CPUs, from P-II to Xeon, it
looks as if after 7 the cpu jumps about 40% to 8, and another 30% to 9.
Neither 8 nor 9 give any significant size improvement (< 2%).
Again, this is 32 bit CPU and just the gzip component, reading from
stdin and writing to stdout which I hope gets directory operations out
of the time measure.
Sample attached.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
[-- Attachment #2: ziptime.log --]
[-- Type: text/plain, Size: 1037 bytes --]
Comp level 1
real 0m1.972s
user 0m1.790s
sys 0m0.098s
-rw-r--r-- 1 davidsen 1792050 Apr 26 11:56 dummy.tar.gz
Comp level 2
real 0m2.021s
user 0m1.858s
sys 0m0.097s
-rw-r--r-- 1 davidsen 1737227 Apr 26 11:56 dummy.tar.gz
Comp level 3
real 0m2.296s
user 0m2.124s
sys 0m0.095s
-rw-r--r-- 1 davidsen 1697644 Apr 26 11:56 dummy.tar.gz
Comp level 4
real 0m2.604s
user 0m2.423s
sys 0m0.099s
-rw-r--r-- 1 davidsen 1593207 Apr 26 11:56 dummy.tar.gz
Comp level 5
real 0m3.181s
user 0m3.003s
sys 0m0.087s
-rw-r--r-- 1 davidsen 1549050 Apr 26 11:56 dummy.tar.gz
Comp level 6
real 0m4.185s
user 0m3.965s
sys 0m0.089s
-rw-r--r-- 1 davidsen 1531866 Apr 26 11:56 dummy.tar.gz
Comp level 7
real 0m4.889s
user 0m4.642s
sys 0m0.096s
-rw-r--r-- 1 davidsen 1524350 Apr 26 11:57 dummy.tar.gz
Comp level 8
real 0m7.836s
user 0m7.532s
sys 0m0.085s
-rw-r--r-- 1 davidsen 1513763 Apr 26 11:57 dummy.tar.gz
Comp level 9
real 0m11.020s
user 0m10.616s
sys 0m0.092s
-rw-r--r-- 1 davidsen 1511970 Apr 26 11:57 dummy.tar.gz
^ permalink raw reply
* [PATCH] Cogito chicken-and-egg problem
From: Pavel Roskin @ 2005-04-26 16:06 UTC (permalink / raw)
To: git
Hello!
My patch for Makefile was misapplied, so installed commit-id is still
needed for "make" to succeed.
Shell commands are processed by make before being passed to the shell,
and $(...) is expanded by make before new PATH is set, as it is done in
the current Makefile.
Also, the dependency on commit-id was dropped from my patch for some
reason. I believe it's still needed. Also, we need a dependency on
cat-file, which is used by commit-id internally.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Index: Makefile
===================================================================
--- f262000f302b749e485f5eb971e6aabefbb85680/Makefile (mode:100644 sha1:4f01bbbbb3fd0e53e9ce968f167b6dae68fcfa92)
+++ uncommitted/Makefile (mode:100644)
@@ -87,11 +87,11 @@
http-pull: LIBS += -lcurl
-cg-version: $(VERSION)
+cg-version: $(VERSION) commit-id cat-file
@echo Generating cg-version...
@rm -f $@
@echo "#!/bin/sh" > $@
- @PATH=.:$(PATH) echo "echo \"$(shell cat $(VERSION)) ($(shell commit-id))\"" >> $@
+ @echo "echo \"$(shell cat $(VERSION)) ($(shell PATH=.:$(PATH) ./commit-id))\"" >> $@
@chmod +x $@
install: $(PROG) $(SCRIPTS) $(SCRIPT) $(GEN_SCRIPT)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: : Networking
From: Daniel Barkalow @ 2005-04-26 15:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, David S. Miller, git
In-Reply-To: <Pine.LNX.4.58.0504260746320.18901@ppc970.osdl.org>
On Tue, 26 Apr 2005, Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Andrew Morton wrote:
> >
>
> The only thing you should be a bit careful about is to remember what the
> "heads" at different points were. In particular, you want to remember
> where you merged with me last was. I've started tagging my releases with
> the git tag facility (_not_ the pasky one, but I think pasky will start
> picking up on that soon enough), so finding a specific release will be
> easy, but if you ever do a non-release merge you'll just have to tag it
> yourself.
Your tag system is in the "cogito-0.8" release, plus a pasky-style way of
keeping track of what tags you have in your repository.
> > d) To generate davem's tree (patch against linus's current tree (ie: patch
> > against 2.6.12-rc3+linus.patch)):
> >
> > git pull git-net
>
> Yes. This should have merged the two (assuming "git pull" does what I
> think it does).
I think git pull only downloads the contents of the repo and saves the new
head in a separate file. You're left to do the merge yourself, in case
what you actually wanted to do was just read the patches in the remote
repo without merging them.
You probably need a "git merge git-net" here, and things will be in the
state that Linus expects.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox