* Hi, Pan-afrikander
From: Dorthy Graham @ 2006-06-15 1:21 UTC (permalink / raw)
To: linux-newbie
Even if you have no erectin problems SOFT CIAzLIS
would help you to make BETTER SE X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER ECTI ON during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER!
http://ltgwos.valvecedar.net/?18867733
==========
As he came from Earth now, above the clouds and in close formation
Pylon 27; the metal sign had a red circle with the number 27 in it. Kirill
about them, to press power into these new wings.
We pulled on the special suits. I poured the nuts and bolts from the
which the style and character of even a laundry list could hardly be
"Don't rush," I said. "No hurry. Less dust."
extraterrestrials, who leave behind them--well, call it litter, such as
1. REDRICK SCHUHART, AGE 23,
^ permalink raw reply
* cvsimport and mozilla
From: Jon Smirl @ 2006-06-15 1:14 UTC (permalink / raw)
To: git, Martin Langhoff
Things are much faster with 3GB memory. I can run cvsps over Mozilla
CVS in 15 minutes now.
cvsps is making branches named 'Branch: #CVSPS_NO_BRANCH' and git is
not happy with this. Ideas on how to fix this?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Shrink "struct object" a bit
From: Linus Torvalds @ 2006-06-14 23:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
NOTE! This shrinks the number of branches that git-show-branch can show
further. It's now 25 instead of 29 (because the three bits required for
the type field, and the previous two bits used for flags. I _think_ it
should have been 30 before, so we really lost 5 bits of the word but
because of the off-by-one, we only lost four branches).
diff --git a/blob.c b/blob.c
index c1fdd86..85deccc 100644
--- a/blob.c
+++ b/blob.c
@@ -10,14 +10,14 @@ struct blob *lookup_blob(const unsigned
if (!obj) {
struct blob *ret = xcalloc(1, sizeof(struct blob));
created_object(sha1, &ret->object);
- ret->object.type = blob_type;
+ ret->object.type = TYPE_BLOB;
return ret;
}
if (!obj->type)
- obj->type = blob_type;
- if (obj->type != blob_type) {
+ obj->type = TYPE_BLOB;
+ if (obj->type != TYPE_BLOB) {
error("Object %s is a %s, not a blob",
- sha1_to_hex(sha1), obj->type);
+ sha1_to_hex(sha1), typename(obj->type));
return NULL;
}
return (struct blob *) obj;
diff --git a/builtin-diff.c b/builtin-diff.c
index 27451d5..6ac3d4b 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -303,9 +303,9 @@ int cmd_diff(int argc, const char **argv
obj = deref_tag(obj, NULL, 0);
if (!obj)
die("invalid object '%s' given.", name);
- if (!strcmp(obj->type, commit_type))
+ if (obj->type == TYPE_COMMIT)
obj = &((struct commit *)obj)->tree->object;
- if (!strcmp(obj->type, tree_type)) {
+ if (obj->type == TYPE_TREE) {
if (ARRAY_SIZE(ent) <= ents)
die("more than %d trees given: '%s'",
(int) ARRAY_SIZE(ent), name);
@@ -315,7 +315,7 @@ int cmd_diff(int argc, const char **argv
ents++;
continue;
}
- if (!strcmp(obj->type, blob_type)) {
+ if (obj->type == TYPE_BLOB) {
if (2 <= blobs)
die("more than two blobs given: '%s'", name);
memcpy(blob[blobs].sha1, obj->sha1, 20);
diff --git a/builtin-grep.c b/builtin-grep.c
index 5fac570..9806499 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -630,10 +630,9 @@ static int grep_tree(struct grep_opt *op
static int grep_object(struct grep_opt *opt, const char **paths,
struct object *obj, const char *name)
{
- if (!strcmp(obj->type, blob_type))
+ if (obj->type == TYPE_BLOB)
return grep_sha1(opt, obj->sha1, name);
- if (!strcmp(obj->type, commit_type) ||
- !strcmp(obj->type, tree_type)) {
+ if (obj->type == TYPE_COMMIT || obj->type == TYPE_TREE) {
struct tree_desc tree;
void *data;
int hit;
@@ -646,7 +645,7 @@ static int grep_object(struct grep_opt *
free(data);
return hit;
}
- die("unable to grep from object of type %s", obj->type);
+ die("unable to grep from object of type %s", typename(obj->type));
}
static const char builtin_grep_usage[] =
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index e885624..2b298c4 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -158,16 +158,16 @@ static void show_commit_list(struct rev_
const char *name = pending->name;
if (obj->flags & (UNINTERESTING | SEEN))
continue;
- if (obj->type == tag_type) {
+ if (obj->type == TYPE_TAG) {
obj->flags |= SEEN;
p = add_object(obj, p, NULL, name);
continue;
}
- if (obj->type == tree_type) {
+ if (obj->type == TYPE_TREE) {
p = process_tree((struct tree *)obj, p, NULL, name);
continue;
}
- if (obj->type == blob_type) {
+ if (obj->type == TYPE_BLOB) {
p = process_blob((struct blob *)obj, p, NULL, name);
continue;
}
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 2895140..cf9c071 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -15,7 +15,7 @@ static const char **default_arg = NULL;
#define UNINTERESTING 01
#define REV_SHIFT 2
-#define MAX_REVS 29 /* should not exceed bits_per_int - REV_SHIFT */
+#define MAX_REVS (FLAG_BITS - REV_SHIFT) /* should not exceed bits_per_int - REV_SHIFT */
static struct commit *interesting(struct commit_list *list)
{
diff --git a/commit.c b/commit.c
index 94f470b..11fca55 100644
--- a/commit.c
+++ b/commit.c
@@ -56,10 +56,10 @@ static struct commit *check_commit(struc
const unsigned char *sha1,
int quiet)
{
- if (obj->type != commit_type) {
+ if (obj->type != TYPE_COMMIT) {
if (!quiet)
error("Object %s is a %s, not a commit",
- sha1_to_hex(sha1), obj->type);
+ sha1_to_hex(sha1), typename(obj->type));
return NULL;
}
return (struct commit *) obj;
@@ -86,11 +86,11 @@ struct commit *lookup_commit(const unsig
if (!obj) {
struct commit *ret = xcalloc(1, sizeof(struct commit));
created_object(sha1, &ret->object);
- ret->object.type = commit_type;
+ ret->object.type = TYPE_COMMIT;
return ret;
}
if (!obj->type)
- obj->type = commit_type;
+ obj->type = TYPE_COMMIT;
return check_commit(obj, sha1, 0);
}
diff --git a/describe.c b/describe.c
index 8a9cd5d..aa3434a 100644
--- a/describe.c
+++ b/describe.c
@@ -67,7 +67,7 @@ static int get_name(const char *path, co
* Otherwise only annotated tags are used.
*/
if (!strncmp(path, "refs/tags/", 10)) {
- if (object->type == tag_type)
+ if (object->type == TYPE_TAG)
prio = 2;
else
prio = 1;
diff --git a/fetch-pack.c b/fetch-pack.c
index 8daa93d..1d676bf 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -40,7 +40,7 @@ static int rev_list_insert_ref(const cha
{
struct object *o = deref_tag(parse_object(sha1), path, 0);
- if (o && o->type == commit_type)
+ if (o && o->type == TYPE_COMMIT)
rev_list_push((struct commit *)o, SEEN);
return 0;
@@ -235,14 +235,14 @@ static int mark_complete(const char *pat
{
struct object *o = parse_object(sha1);
- while (o && o->type == tag_type) {
+ while (o && o->type == TYPE_TAG) {
struct tag *t = (struct tag *) o;
if (!t->tagged)
break; /* broken repository */
o->flags |= COMPLETE;
o = parse_object(t->tagged->sha1);
}
- if (o && o->type == commit_type) {
+ if (o && o->type == TYPE_COMMIT) {
struct commit *commit = (struct commit *)o;
commit->object.flags |= COMPLETE;
insert_by_date(commit, &complete);
@@ -336,7 +336,7 @@ static int everything_local(struct ref *
* in sync with the other side at some time after
* that (it is OK if we guess wrong here).
*/
- if (o->type == commit_type) {
+ if (o->type == TYPE_COMMIT) {
struct commit *commit = (struct commit *)o;
if (!cutoff || cutoff < commit->date)
cutoff = commit->date;
@@ -355,7 +355,7 @@ static int everything_local(struct ref *
struct object *o = deref_tag(lookup_object(ref->old_sha1),
NULL, 0);
- if (!o || o->type != commit_type || !(o->flags & COMPLETE))
+ if (!o || o->type != TYPE_COMMIT || !(o->flags & COMPLETE))
continue;
if (!(o->flags & SEEN)) {
diff --git a/fetch.c b/fetch.c
index cf6c994..238032b 100644
--- a/fetch.c
+++ b/fetch.c
@@ -118,27 +118,27 @@ static struct object_list **process_queu
static int process_object(struct object *obj)
{
- if (obj->type == commit_type) {
+ if (obj->type == TYPE_COMMIT) {
if (process_commit((struct commit *)obj))
return -1;
return 0;
}
- if (obj->type == tree_type) {
+ if (obj->type == TYPE_TREE) {
if (process_tree((struct tree *)obj))
return -1;
return 0;
}
- if (obj->type == blob_type) {
+ if (obj->type == TYPE_BLOB) {
return 0;
}
- if (obj->type == tag_type) {
+ if (obj->type == TYPE_TAG) {
if (process_tag((struct tag *)obj))
return -1;
return 0;
}
return error("Unable to determine requirements "
"of type %s for %s",
- obj->type, sha1_to_hex(obj->sha1));
+ typename(obj->type), sha1_to_hex(obj->sha1));
}
static int process(struct object *obj)
@@ -179,9 +179,7 @@ static int loop(void)
*/
if (! (obj->flags & TO_SCAN)) {
if (fetch(obj->sha1)) {
- report_missing(obj->type
- ? obj->type
- : "object", obj->sha1);
+ report_missing(typename(obj->type), obj->sha1);
return -1;
}
}
diff --git a/fsck-objects.c b/fsck-objects.c
index 33ce366..99b419e 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -34,7 +34,7 @@ static void objreport(struct object *obj
const char *err, va_list params)
{
fprintf(stderr, "%s in %s %s: ",
- severity, obj->type, sha1_to_hex(obj->sha1));
+ severity, typename(obj->type), sha1_to_hex(obj->sha1));
vfprintf(stderr, err, params);
fputs("\n", stderr);
}
@@ -74,7 +74,7 @@ static void check_connectivity(void)
; /* it is in pack */
else
printf("missing %s %s\n",
- obj->type, sha1_to_hex(obj->sha1));
+ typename(obj->type), sha1_to_hex(obj->sha1));
continue;
}
@@ -87,20 +87,20 @@ static void check_connectivity(void)
(has_sha1_file(ref->sha1)))
continue;
printf("broken link from %7s %s\n",
- obj->type, sha1_to_hex(obj->sha1));
+ typename(obj->type), sha1_to_hex(obj->sha1));
printf(" to %7s %s\n",
- ref->type, sha1_to_hex(ref->sha1));
+ typename(ref->type), sha1_to_hex(ref->sha1));
}
}
if (show_unreachable && !(obj->flags & REACHABLE)) {
printf("unreachable %s %s\n",
- obj->type, sha1_to_hex(obj->sha1));
+ typename(obj->type), sha1_to_hex(obj->sha1));
continue;
}
if (!obj->used) {
- printf("dangling %s %s\n", obj->type,
+ printf("dangling %s %s\n", typename(obj->type),
sha1_to_hex(obj->sha1));
}
}
@@ -282,7 +282,7 @@ static int fsck_tag(struct tag *tag)
if (!show_tags)
return 0;
- printf("tagged %s %s", tagged->type, sha1_to_hex(tagged->sha1));
+ printf("tagged %s %s", typename(tagged->type), sha1_to_hex(tagged->sha1));
printf(" (%s) in %s\n", tag->tag, sha1_to_hex(tag->object.sha1));
return 0;
}
@@ -295,16 +295,16 @@ static int fsck_sha1(unsigned char *sha1
if (obj->flags & SEEN)
return 0;
obj->flags |= SEEN;
- if (obj->type == blob_type)
+ if (obj->type == TYPE_BLOB)
return 0;
- if (obj->type == tree_type)
+ if (obj->type == TYPE_TREE)
return fsck_tree((struct tree *) obj);
- if (obj->type == commit_type)
+ if (obj->type == TYPE_COMMIT)
return fsck_commit((struct commit *) obj);
- if (obj->type == tag_type)
+ if (obj->type == TYPE_TAG)
return fsck_tag((struct tag *) obj);
/* By now, parse_object() would've returned NULL instead. */
- return objerror(obj, "unknown type '%s' (internal fsck error)", obj->type);
+ return objerror(obj, "unknown type '%d' (internal fsck error)", obj->type);
}
/*
@@ -470,7 +470,7 @@ static int fsck_cache_tree(struct cache_
}
mark_reachable(obj, REACHABLE);
obj->used = 1;
- if (obj->type != tree_type)
+ if (obj->type != TYPE_TREE)
err |= objerror(obj, "non-tree in cache-tree");
}
for (i = 0; i < it->subtree_nr; i++)
diff --git a/http-push.c b/http-push.c
index b39b36b..599929e 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1773,16 +1773,16 @@ static int get_delta(struct rev_info *re
if (obj->flags & (UNINTERESTING | SEEN))
continue;
- if (obj->type == tag_type) {
+ if (obj->type == TYPE_TAG) {
obj->flags |= SEEN;
p = add_object(obj, p, NULL, name);
continue;
}
- if (obj->type == tree_type) {
+ if (obj->type == TYPE_TREE) {
p = process_tree((struct tree *)obj, p, NULL, name);
continue;
}
- if (obj->type == blob_type) {
+ if (obj->type == TYPE_BLOB) {
p = process_blob((struct blob *)obj, p, NULL, name);
continue;
}
@@ -1949,12 +1949,12 @@ static int ref_newer(const unsigned char
* old. Otherwise we require --force.
*/
o = deref_tag(parse_object(old_sha1), NULL, 0);
- if (!o || o->type != commit_type)
+ if (!o || o->type != TYPE_COMMIT)
return 0;
old = (struct commit *) o;
o = deref_tag(parse_object(new_sha1), NULL, 0);
- if (!o || o->type != commit_type)
+ if (!o || o->type != TYPE_COMMIT)
return 0;
new = (struct commit *) o;
@@ -2033,7 +2033,7 @@ static void add_remote_info_ref(struct r
fwrite_buffer(ref_info, 1, len, buf);
free(ref_info);
- if (o->type == tag_type) {
+ if (o->type == TYPE_TAG) {
o = deref_tag(o, ls->dentry_name, 0);
if (o) {
len = strlen(ls->dentry_name) + 45;
diff --git a/name-rev.c b/name-rev.c
index bad8a53..1f0135f 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -84,14 +84,14 @@ static int name_ref(const char *path, co
if (tags_only && strncmp(path, "refs/tags/", 10))
return 0;
- while (o && o->type == tag_type) {
+ while (o && o->type == TYPE_TAG) {
struct tag *t = (struct tag *) o;
if (!t->tagged)
break; /* broken repository */
o = parse_object(t->tagged->sha1);
deref = 1;
}
- if (o && o->type == commit_type) {
+ if (o && o->type == TYPE_COMMIT) {
struct commit *commit = (struct commit *)o;
if (!strncmp(path, "refs/heads/", 11))
@@ -167,7 +167,7 @@ int main(int argc, char **argv)
}
o = deref_tag(parse_object(sha1), *argv, 0);
- if (!o || o->type != commit_type) {
+ if (!o || o->type != TYPE_COMMIT) {
fprintf(stderr, "Could not get commit for %s. Skipping.\n",
*argv);
continue;
diff --git a/object.c b/object.c
index 9adc874..0f70890 100644
--- a/object.c
+++ b/object.c
@@ -9,6 +9,10 @@ struct object **objs;
static int nr_objs;
int obj_allocs;
+const char *type_names[] = {
+ "none", "blob", "tree", "commit", "bad"
+};
+
int track_object_refs = 0;
static int hashtable_index(const unsigned char *sha1)
@@ -50,7 +54,7 @@ void created_object(const unsigned char
obj->parsed = 0;
memcpy(obj->sha1, sha1, 20);
- obj->type = NULL;
+ obj->type = TYPE_NONE;
obj->refs = NULL;
obj->used = 0;
@@ -179,7 +183,7 @@ struct object *lookup_unknown_object(con
if (!obj) {
union any_object *ret = xcalloc(1, sizeof(*ret));
created_object(sha1, &ret->object);
- ret->object.type = NULL;
+ ret->object.type = TYPE_NONE;
return &ret->object;
}
return obj;
diff --git a/object.h b/object.h
index e08afbd..a0762b6 100644
--- a/object.h
+++ b/object.h
@@ -12,12 +12,22 @@ struct object_refs {
struct object *ref[FLEX_ARRAY]; /* more */
};
+#define TYPE_BITS 3
+#define FLAG_BITS 27
+
+#define TYPE_NONE 0
+#define TYPE_BLOB 1
+#define TYPE_TREE 2
+#define TYPE_COMMIT 3
+#define TYPE_TAG 4
+#define TYPE_BAD 5
+
struct object {
unsigned parsed : 1;
unsigned used : 1;
- unsigned int flags;
+ unsigned type : TYPE_BITS;
+ unsigned flags : FLAG_BITS;
unsigned char sha1[20];
- const char *type;
struct object_refs *refs;
void *util;
};
@@ -25,6 +35,12 @@ struct object {
extern int track_object_refs;
extern int obj_allocs;
extern struct object **objs;
+extern const char *type_names[];
+
+static inline const char *typename(unsigned int type)
+{
+ return type_names[type > TYPE_TAG ? TYPE_BAD : type];
+}
/** Internal only **/
struct object *lookup_object(const unsigned char *sha1);
diff --git a/revision.c b/revision.c
index 6a6952c..f4b8826 100644
--- a/revision.c
+++ b/revision.c
@@ -140,7 +140,7 @@ static struct commit *handle_commit(stru
/*
* Tag object? Look what it points to..
*/
- while (object->type == tag_type) {
+ while (object->type == TYPE_TAG) {
struct tag *tag = (struct tag *) object;
if (revs->tag_objects && !(flags & UNINTERESTING))
add_pending_object(revs, object, tag->tag);
@@ -153,7 +153,7 @@ static struct commit *handle_commit(stru
* Commit object? Just return it, we'll do all the complex
* reachability crud.
*/
- if (object->type == commit_type) {
+ if (object->type == TYPE_COMMIT) {
struct commit *commit = (struct commit *)object;
if (parse_commit(commit) < 0)
die("unable to parse commit %s", name);
@@ -169,7 +169,7 @@ static struct commit *handle_commit(stru
* Tree object? Either mark it uniniteresting, or add it
* to the list of objects to look at later..
*/
- if (object->type == tree_type) {
+ if (object->type == TYPE_TREE) {
struct tree *tree = (struct tree *)object;
if (!revs->tree_objects)
return NULL;
@@ -184,7 +184,7 @@ static struct commit *handle_commit(stru
/*
* Blob object? You know the drill by now..
*/
- if (object->type == blob_type) {
+ if (object->type == TYPE_BLOB) {
struct blob *blob = (struct blob *)object;
if (!revs->blob_objects)
return NULL;
@@ -498,11 +498,11 @@ static int add_parents_only(struct rev_i
return 0;
while (1) {
it = get_reference(revs, arg, sha1, 0);
- if (strcmp(it->type, tag_type))
+ if (it->type != TYPE_TAG)
break;
memcpy(sha1, ((struct tag*)it)->tagged->sha1, 20);
}
- if (strcmp(it->type, commit_type))
+ if (it->type != TYPE_COMMIT)
return 0;
commit = (struct commit *)it;
for (parents = commit->parents; parents; parents = parents->next) {
diff --git a/send-pack.c b/send-pack.c
index 409f188..af93b11 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -151,12 +151,12 @@ static int ref_newer(const unsigned char
* old. Otherwise we require --force.
*/
o = deref_tag(parse_object(old_sha1), NULL, 0);
- if (!o || o->type != commit_type)
+ if (!o || o->type != TYPE_COMMIT)
return 0;
old = (struct commit *) o;
o = deref_tag(parse_object(new_sha1), NULL, 0);
- if (!o || o->type != commit_type)
+ if (!o || o->type != TYPE_COMMIT)
return 0;
new = (struct commit *) o;
diff --git a/server-info.c b/server-info.c
index 05bce7d..0eb5132 100644
--- a/server-info.c
+++ b/server-info.c
@@ -12,7 +12,7 @@ static int add_info_ref(const char *path
struct object *o = parse_object(sha1);
fprintf(info_ref_fp, "%s %s\n", sha1_to_hex(sha1), path);
- if (o->type == tag_type) {
+ if (o->type == TYPE_TAG) {
o = deref_tag(o, path, 0);
if (o)
fprintf(info_ref_fp, "%s %s^{}\n",
diff --git a/sha1_name.c b/sha1_name.c
index fbbde1c..8463d4b 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -358,7 +358,7 @@ static int peel_onion(const char *name,
{
unsigned char outer[20];
const char *sp;
- const char *type_string = NULL;
+ unsigned int expected_type = 0;
struct object *o;
/*
@@ -382,13 +382,13 @@ static int peel_onion(const char *name,
sp++; /* beginning of type name, or closing brace for empty */
if (!strncmp(commit_type, sp, 6) && sp[6] == '}')
- type_string = commit_type;
+ expected_type = TYPE_COMMIT;
else if (!strncmp(tree_type, sp, 4) && sp[4] == '}')
- type_string = tree_type;
+ expected_type = TYPE_TREE;
else if (!strncmp(blob_type, sp, 4) && sp[4] == '}')
- type_string = blob_type;
+ expected_type = TYPE_BLOB;
else if (sp[0] == '}')
- type_string = NULL;
+ expected_type = TYPE_NONE;
else
return -1;
@@ -398,7 +398,7 @@ static int peel_onion(const char *name,
o = parse_object(outer);
if (!o)
return -1;
- if (!type_string) {
+ if (!expected_type) {
o = deref_tag(o, name, sp - name - 2);
if (!o || (!o->parsed && !parse_object(o->sha1)))
return -1;
@@ -413,18 +413,18 @@ static int peel_onion(const char *name,
while (1) {
if (!o || (!o->parsed && !parse_object(o->sha1)))
return -1;
- if (o->type == type_string) {
+ if (o->type == expected_type) {
memcpy(sha1, o->sha1, 20);
return 0;
}
- if (o->type == tag_type)
+ if (o->type == TYPE_TAG)
o = ((struct tag*) o)->tagged;
- else if (o->type == commit_type)
+ else if (o->type == TYPE_COMMIT)
o = &(((struct commit *) o)->tree->object);
else
return error("%.*s: expected %s type, but the object dereferences to %s type",
- len, name, type_string,
- o->type);
+ len, name, typename(expected_type),
+ typename(o->type));
if (!o->parsed)
parse_object(o->sha1);
}
diff --git a/tag.c b/tag.c
index f390ee7..24ea6f6 100644
--- a/tag.c
+++ b/tag.c
@@ -5,7 +5,7 @@ const char *tag_type = "tag";
struct object *deref_tag(struct object *o, const char *warn, int warnlen)
{
- while (o && o->type == tag_type)
+ while (o && o->type == TYPE_TAG)
o = parse_object(((struct tag *)o)->tagged->sha1);
if (!o && warn) {
if (!warnlen)
@@ -21,14 +21,14 @@ struct tag *lookup_tag(const unsigned ch
if (!obj) {
struct tag *ret = xcalloc(1, sizeof(struct tag));
created_object(sha1, &ret->object);
- ret->object.type = tag_type;
+ ret->object.type = TYPE_TAG;
return ret;
}
if (!obj->type)
- obj->type = tag_type;
- if (obj->type != tag_type) {
+ obj->type = TYPE_TAG;
+ if (obj->type != TYPE_TAG) {
error("Object %s is a %s, not a tree",
- sha1_to_hex(sha1), obj->type);
+ sha1_to_hex(sha1), typename(obj->type));
return NULL;
}
return (struct tag *) obj;
diff --git a/tree.c b/tree.c
index 9bbe2da..9277715 100644
--- a/tree.c
+++ b/tree.c
@@ -131,14 +131,14 @@ struct tree *lookup_tree(const unsigned
if (!obj) {
struct tree *ret = xcalloc(1, sizeof(struct tree));
created_object(sha1, &ret->object);
- ret->object.type = tree_type;
+ ret->object.type = TYPE_TREE;
return ret;
}
if (!obj->type)
- obj->type = tree_type;
- if (obj->type != tree_type) {
+ obj->type = TYPE_TREE;
+ if (obj->type != TYPE_TREE) {
error("Object %s is a %s, not a tree",
- sha1_to_hex(sha1), obj->type);
+ sha1_to_hex(sha1), typename(obj->type));
return NULL;
}
return (struct tree *) obj;
@@ -216,11 +216,11 @@ struct tree *parse_tree_indirect(const u
do {
if (!obj)
return NULL;
- if (obj->type == tree_type)
+ if (obj->type == TYPE_TREE)
return (struct tree *) obj;
- else if (obj->type == commit_type)
+ else if (obj->type == TYPE_COMMIT)
obj = &(((struct commit *) obj)->tree->object);
- else if (obj->type == tag_type)
+ else if (obj->type == TYPE_TAG)
obj = ((struct tag *) obj)->tagged;
else
return NULL;
diff --git a/upload-pack.c b/upload-pack.c
index 47560c9..979e583 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -105,7 +105,7 @@ static int got_sha1(char *hex, unsigned
o = parse_object(sha1);
if (!o)
die("oops (%s)", sha1_to_hex(sha1));
- if (o->type == commit_type) {
+ if (o->type == TYPE_COMMIT) {
struct commit_list *parents;
if (o->flags & THEY_HAVE)
return 0;
@@ -234,7 +234,7 @@ static int send_ref(const char *refname,
o->flags |= OUR_REF;
nr_our_refs++;
}
- if (o->type == tag_type) {
+ if (o->type == TYPE_TAG) {
o = deref_tag(o, refname, 0);
packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname);
}
^ permalink raw reply related
* Re: Autoconf/Automake
From: Timo Hirvonen @ 2006-06-14 23:18 UTC (permalink / raw)
To: proski; +Cc: git
In-Reply-To: <1150324030.23268.12.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> Hello!
>
> Is there any interest in converting the build system used by git to
> Autoconf and Automake? The ad-hoc configuration in Makefile is getting
> too big. As for nice features like remembering $prefix, wouldn't it be
> better to add them to Automake instead of limiting them to just one
> project?
>
> Other goodies from Automake are "make distcheck" and automatic
> dependency tracking. Compatibility with non-GNU make could earn us some
> respect from BSD folks.
>
> I converted several projects to the GNU build system, including qgit.
> It may be hard to get right, but then it just works for any
> configuration without giving any trouble.
Autotools almost drove me crazy so I had to write my own configure
system:
http://onion.dynserv.net/~timo/tconf.html
It is really easy to use and quite flexible.</shameless plug>
Personally I don't think git needs autoconf/tconf/whatever. The current
makefile is good enough.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Autoconf/Automake
From: Bertrand Jacquin @ 2006-06-14 22:54 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1150324030.23268.12.camel@dv>
On 6/15/06, Pavel Roskin <proski@gnu.org> wrote:
> Hello!
>
> Is there any interest in converting the build system used by git to
> Autoconf and Automake? The ad-hoc configuration in Makefile is getting
> too big. As for nice features like remembering $prefix, wouldn't it be
> better to add them to Automake instead of limiting them to just one
> project?
Autofoo are pretty good but it's unix make dependant, can't create
build files for other build system as Visual, or so on. How don't lost
his hairs trying to do autofood his project ?
CMake seems to be as good for git. And is also expansible.
Git Makefile is quiet big but not complex, autofood imho will make it
less stable and usable.
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* Re: Autoconf/Automake
From: Linus Torvalds @ 2006-06-14 22:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1150324030.23268.12.camel@dv>
On Wed, 14 Jun 2006, Pavel Roskin wrote:
>
> Is there any interest in converting the build system used by git to
> Autoconf and Automake? The ad-hoc configuration in Makefile is getting
> too big.
NO! At least the Makefile is debuggable and understandable.
If we need a better build system, I'd much rather use something
higher-level that can generate VC++ project files etc.
In other words, I'd much rather see us using CMake or something like that,
which actually adds real value-add.
(And no, I've never used cmake, so maybe it has horrors waiting for us
too, but autoconf is just worthless).
Linus
^ permalink raw reply
* [PATCH] auto-detect changed prefix and/or changed build flags
From: Yakov Lerner @ 2006-06-14 22:36 UTC (permalink / raw)
To: git; +Cc: iler.ml
Detect changed prefix and/or changed build flags in the middle
of the build (or between 'make' and 'make install'), and if change
is detected, make sure all objects are compiled with same build
flags and same prefix, thus avoiding inconsistent/broken build.
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
---
Makefile | 36 +++++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -464,6 +464,7 @@
bindir_SQ = $(subst ','\'',$(bindir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
+prefix_SQ = $(subst ','\'',$(prefix))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -484,7 +485,7 @@
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
-git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS)
+git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS) GIT-CFLAGS
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(ALL_CFLAGS) -o $@ $(filter %.c,$^) \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
@@ -516,7 +517,7 @@
chmod +x $@+
mv $@+ $@
-$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
+$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py GIT-CFLAGS
rm -f $@ $@+
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
@@ -540,19 +541,19 @@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
: GIT-VERSION-FILE
-%.o: %.c
+%.o: %.c GIT-CFLAGS
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
%.o: %.S
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-exec_cmd.o: exec_cmd.c
+exec_cmd.o: exec_cmd.c GIT-CFLAGS
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
-http.o: http.c
+http.o: http.c GIT-CFLAGS
$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
ifdef NO_EXPAT
-http-fetch.o: http-fetch.c http.h
+http-fetch.o: http-fetch.c http.h GIT-CFLAGS
$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
endif
@@ -609,6 +610,17 @@
rm -f tags
find . -name '*.[hcS]' -print | xargs ctags -a
+### Detect prefix changes
+TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):$(GIT_VERSION):\
+ $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
+
+GIT-CFLAGS: .FORCE-GIT-CFLAGS
+ @FLAGS='$(TRACK_CFLAGS)'; \
+ if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
+ echo 1>&2 " * new build flags or prefix"; \
+ echo "$$FLAGS" >GIT-CFLAGS; \
+ fi
+
### Testing rules
# GNU make supports exporting all variables by "export" without parameters.
@@ -632,6 +644,12 @@
check:
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
+test-prefix-change:
+ mkdir -p "`pwd`/tmp1" "`pwd`/tmp2"
+ $(MAKE) clean install prefix="`pwd`/tmp1"
+ $(MAKE) install prefix="`pwd`/tmp2"
+ @grep -r "`pwd`/tmp1" "`pwd`/tmp2" >/dev/null; if test $$? = 0 ; then\
+ echo Error, test failed; exit 1; else echo Ok, test passed; fi
### Installation rules
@@ -705,16 +723,16 @@
$(LIB_FILE) $(XDIFF_LIB)
rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
- rm -rf $(GIT_TARNAME) .doc-tmp-dir
+ rm -rf $(GIT_TARNAME) .doc-tmp-dir tmp1 tmp2
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
$(MAKE) -C Documentation/ clean
$(MAKE) -C templates clean
$(MAKE) -C t/ clean
- rm -f GIT-VERSION-FILE
+ rm -f GIT-VERSION-FILE GIT-CFLAGS
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
### Check documentation
#
^ permalink raw reply
* Autoconf/Automake
From: Pavel Roskin @ 2006-06-14 22:27 UTC (permalink / raw)
To: git
Hello!
Is there any interest in converting the build system used by git to
Autoconf and Automake? The ad-hoc configuration in Makefile is getting
too big. As for nice features like remembering $prefix, wouldn't it be
better to add them to Automake instead of limiting them to just one
project?
Other goodies from Automake are "make distcheck" and automatic
dependency tracking. Compatibility with non-GNU make could earn us some
respect from BSD folks.
I converted several projects to the GNU build system, including qgit.
It may be hard to get right, but then it just works for any
configuration without giving any trouble.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Yakov Lerner @ 2006-06-14 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd2nctjk.fsf@assigned-by-dhcp.cox.net>
On 6/15/06, Junio C Hamano <junkio@cox.net> wrote:
> "Yakov Lerner" <iler.ml@gmail.com> writes:
>
> > I think single GIT-BUILD-FLAGS
> > is enough, which will cover prefixes, too. Is this OK ?
>
> Yes, it was what I was getting at. I think a single
> GIT-BUILD-FLAGS (or whatever name the list can fight over while
> I am away) is preferred.
Either GIT-CFLAGS or GIT-BUILD-FLAGS,
whichever is shorter :-)
Yakov
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-14 21:32 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Junio C Hamano, git
In-Reply-To: <f36b08ee0606141330l28330d79hab1aec5c741188c7@mail.gmail.com>
"Yakov Lerner" <iler.ml@gmail.com> writes:
> I think single GIT-BUILD-FLAGS
> is enough, which will cover prefixes, too. Is this OK ?
Yes, it was what I was getting at. I think a single
GIT-BUILD-FLAGS (or whatever name the list can fight over while
I am away) is preferred.
> BTW, I think it's useful to add Makefile itself as prerequisite for all *.o,
> so change in Makefile will cause recompilations. Shall I include this
> into this patch, too ?
I've thought about it but in practice this would make things
more inconvenient for developers without much gain, so I'd leave
it out.
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Nicolas Pitre @ 2006-06-14 21:20 UTC (permalink / raw)
To: Keith Packard; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <1150319115.30681.54.camel@neko.keithp.com>
On Wed, 14 Jun 2006, Keith Packard wrote:
> Hmm. As I'm deltafying along branches, the delta data should actually be
> fairly good; the only 'bad' result will be the sub-optimal object
> ordering in the pack files. I'll experiment with some larger trees to
> see how much additional savings the various repack options yield.
Note that the object list order is unlikely to affect pack size. It is
really about optimizing the pack layout for subsequent access to it.
Nicolas
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Linus Torvalds @ 2006-06-14 21:17 UTC (permalink / raw)
To: Keith Packard; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <1150319115.30681.54.camel@neko.keithp.com>
On Wed, 14 Jun 2006, Keith Packard wrote:
>
> > In that case it
> > might be preferable that the reuse of already deltified data is made of
> > backward delta which is the reason you might consider feeding object in
> > the prefered order up front.
>
> Hmm. As I'm deltafying along branches, the delta data should actually be
> fairly good; the only 'bad' result will be the sub-optimal object
> ordering in the pack files. I'll experiment with some larger trees to
> see how much additional savings the various repack options yield.
The fact that git repacking sorts by filesize after it sorts by filename
should make this a non-issue: we always try to delta against the larger
version (where "larger" is not only almost invariable also "newer", but
the delta is simpler, since deleting data doesn't take up any space in the
delta, while adding data needs to ay what the data added was, of course).
Linus
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Keith Packard @ 2006-06-14 21:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: keithp, Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606141514000.2703@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
On Wed, 2006-06-14 at 15:25 -0400, Nicolas Pitre wrote:
> The only advantage of feeding object names from latest to oldest has to
> do with the delta direction. In doing so the delta are backward such
> that objects with deeper delta chain are further back in history and
> this is what you want in the final pack for faster access to the latest
> revision.
Ok, so I'm feeding them from latest to oldest along each branch, which
optimizes only the 'master' branch, leaving other branches much further
down in the data file. That should mean repacking will help a lot for
repositories with many active branches.
> In that case it
> might be preferable that the reuse of already deltified data is made of
> backward delta which is the reason you might consider feeding object in
> the prefered order up front.
Hmm. As I'm deltafying along branches, the delta data should actually be
fairly good; the only 'bad' result will be the sub-optimal object
ordering in the pack files. I'll experiment with some larger trees to
see how much additional savings the various repack options yield.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-diff --cc broken in 1.4.0?
From: Martin Langhoff @ 2006-06-14 20:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzcfcwb5.fsf@assigned-by-dhcp.cox.net>
On 6/15/06, Junio C Hamano <junkio@cox.net> wrote:
> One thing to note is that --cc does not show a hunk in which you
> take only from one side.
Must have been that. I was looking at a big (but clean) merge, and
where gitk used to show a large-ish diff there was nothing. I somehow
expected an even larger diff with the changes against both sides.
thanks for the clarification and sorry about that!
m
^ permalink raw reply
* Re: git-diff --cc broken in 1.4.0?
From: Junio C Hamano @ 2006-06-14 20:32 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606112132jaf33a25x5794a19db2a06d8d@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> I was looking at some merges in gitk and lamenting the apparent loss
> of the nice two-sided diff we get with -cc, and now duting a slightly
> messy merge I did git-diff -cc only to get...
This not a regression that I know of in 1.4.0; mind showing the
stage 2 and 3 blobs and the file in the resolution result (I do
not need stage 1)?
One thing to note is that --cc does not show a hunk in which you
take only from one side.
>
> $ git-ls-files --unmerged
> 100644 f1d3843b2b2e42ba78adcf37da6440f0d321852e 1 local/version.php
> 100644 9352efa45cd25d9ad58df12b4ac241ac226a8ad4 2 local/version.php
> 100644 50da9b47903f6179f55a3f44290e7feaa08342f4 3 local/version.php
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Yakov Lerner @ 2006-06-14 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vver3cxlw.fsf@assigned-by-dhcp.cox.net>
On 6/14/06, Junio C Hamano <junkio@cox.net> wrote:
> Yakov Lerner <iler.ml@gmail.com> writes:
>
> > Many times, I mistakenly used 'make prefix=... install' where prefix value
> > was different from prefix value during build. This resulted in broken
> > install. This patch adds auto-detection of $prefix change to the Makefile.
> > This results in correct install whenever prefix is changed.
> >
> > Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
>
> I do not mind this per se, and probably even agree that this is
> an improvement compared to the current state of affairs, but a few
> points:
>
> - please make sure you clean that state file in "make clean";
done
> - we may want to make the state file a bit more visible (IOW, I
> somewhat do mind the name being dot-git-dot-prefix).
I renamed .git.prefix to GIT-PREFIX. Is this ok.
> - we might want to later (or at the same time as this patch)
> do "consistent set of compilation flags" (e.g. run early
> part of compilation with openssl SHA-1 implementation,
> interrupt it and build and link the rest with mozilla SHA-1
> implementation -- then you will get a nonsense binary without
> linker errors). It might make sense to prepare this
> mechanism so we could reuse it for that purpose.
Do you think two separate GIT-PREFIX and GIT-BUILD-FLAGS are needed,
or just once GIT-BUILD-FLAGS will do, which will include
prefixes (as passed with -D... to cc) ?
I think single GIT-BUILD-FLAGS
is enough, which will cover prefixes, too. Is this OK ?
BTW, I think it's useful to add Makefile itself as prerequisite for all *.o,
so change in Makefile will cause recompilations. Shall I include this
into this patch, too ?
Yakov
^ permalink raw reply
* Re: [PATCH] gitweb: Adding a `blame' interface.
From: Junio C Hamano @ 2006-06-14 20:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Florian Forster, git
In-Reply-To: <46a038f90606111502g607be3cfnf83ce81764a5f909@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Florian,
>
> Looks good! git-blame/git-annotate are quite expensive to run. Do you
> think it would make sense making it conditional on a git-repo-config
> option (gitweb.blame=1)?
>
> kernel.org is the flagship user for gitweb, so expensive options
> should default to off :-/
Seconded. Thanks Florian and Martin.
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-14 20:04 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <0J0V00LDT7B9BU00@mxout2.netvision.net.il>
Yakov Lerner <iler.ml@gmail.com> writes:
> Many times, I mistakenly used 'make prefix=... install' where prefix value
> was different from prefix value during build. This resulted in broken
> install. This patch adds auto-detection of $prefix change to the Makefile.
> This results in correct install whenever prefix is changed.
>
> Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
I do not mind this per se, and probably even agree that this is
an improvement compared to the current state of affairs, but a few
points:
- please make sure you clean that state file in "make clean";
- we may want to make the state file a bit more visible (IOW, I
somewhat do mind the name being dot-git-dot-prefix).
- we might want to later (or at the same time as this patch)
do "consistent set of compilation flags" (e.g. run early
part of compilation with openssl SHA-1 implementation,
interrupt it and build and link the rest with mozilla SHA-1
implementation -- then you will get a nonsense binary without
linker errors). It might make sense to prepare this
mechanism so we could reuse it for that purpose.
^ permalink raw reply
* Re: oprofile on svn import
From: Jakub Narebski @ 2006-06-14 19:38 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910606141225n11b406fte6229ea9993825dd@mail.gmail.com>
Jon Smirl wrote:
> Stats after 18 hours into git-svnimport. Process is now stuck in the
> kernel 64% of the time. All of the kernel time is in page management.
> Perl svnimport process is 290MB now.
>
> My top candidates for causing the problem are the fork in the perl
> code or the execing of a million tiny git processes.
>
> The key low level git functions could be made into a library to avoid
> the need to exec them continuously. The svn functions are libraries
> and they hardly show up.
There is ongoing effort to translate git functions into builtins.
Still you would need to translate git-svnimport Perl code into C,
or somehow access git library from Perl.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Yakov Lerner @ 2006-06-14 19:26 UTC (permalink / raw)
To: git; +Cc: iler.ml
Many times, I mistakenly used 'make prefix=... install' where prefix value
was different from prefix value during build. This resulted in broken
install. This patch adds auto-detection of $prefix change to the Makefile.
This results in correct install whenever prefix is changed.
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
---
Makefile | 29 ++++++++++++++++++++++-------
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 2a1e639..015c9b2 100644
--- a/Makefile
+++ b/Makefile
@@ -464,6 +464,7 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
+prefix_SQ = $(subst ','\'',$(prefix))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -484,7 +485,7 @@ all:
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
-git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS)
+git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS) .git.prefix
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(ALL_CFLAGS) -o $@ $(filter %.c,$^) \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
@@ -516,7 +517,7 @@ common-cmds.h: Documentation/git-*.txt
chmod +x $@+
mv $@+ $@
-$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
+$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py .git.prefix
rm -f $@ $@+
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
@@ -540,19 +541,19 @@ git$X git.spec \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
: GIT-VERSION-FILE
-%.o: %.c
+%.o: %.c .git.prefix
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
%.o: %.S
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-exec_cmd.o: exec_cmd.c
+exec_cmd.o: exec_cmd.c .git.prefix
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
-http.o: http.c
+http.o: http.c .git.prefix
$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
ifdef NO_EXPAT
-http-fetch.o: http-fetch.c http.h
+http-fetch.o: http-fetch.c http.h .git.prefix
$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
endif
@@ -609,6 +610,14 @@ tags:
rm -f tags
find . -name '*.[hcS]' -print | xargs ctags -a
+### Detect prefix changes
+.git.prefix: .FORCE-git.prefix
+ @PREFIXES='$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)';\
+ if test x"$$PREFIXES" != x"`cat .git.prefix 2>/dev/null`" ; then \
+ echo 1>&2 " * prefix changed"; \
+ echo "$$PREFIXES" >.git.prefix; \
+ fi
+
### Testing rules
# GNU make supports exporting all variables by "export" without parameters.
@@ -632,6 +641,12 @@ test-dump-cache-tree$X: dump-cache-tree.
check:
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
+test-prefix-change:
+ mkdir -p "`pwd`/tmp1" "`pwd`/tmp2"
+ $(MAKE) clean install prefix="`pwd`/tmp1"
+ $(MAKE) install prefix="`pwd`/tmp2"
+ @grep -r "`pwd`/tmp1" "`pwd`/tmp2" >/dev/null; if test $$? = 0 ; then\
+ echo Error, test failed; exit 1; else echo Ok, test passed; fi
### Installation rules
@@ -714,7 +729,7 @@ clean:
rm -f GIT-VERSION-FILE
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-git.prefix
### Check documentation
#
--
1.4.0
^ permalink raw reply related
* Re: oprofile on svn import
From: Jon Smirl @ 2006-06-14 19:25 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910606131932w362c6ddcx5bf36ea5591feba1@mail.gmail.com>
Stats after 18 hours into git-svnimport. Process is now stuck in the
kernel 64% of the time. All of the kernel time is in page management.
Perl svnimport process is 290MB now.
My top candidates for causing the problem are the fork in the perl
code or the execing of a million tiny git processes.
The key low level git functions could be made into a library to avoid
the need to exec them continuously. The svn functions are libraries
and they hardly show up.
606218 2.4143 /usr/local/bin/git-update-index
127170 0.5065 /usr/local/bin/git-write-tree
81153 0.3232 /usr/local/bin/git-read-tree
13065 0.0520 /usr/local/bin/git-ls-files
2624 0.0105 /usr/local/bin/git-hash-object
754 0.0030 /usr/local/bin/git-commit-tree
462 0.0018 /usr/local/bin/git-ls-tree
398 0.0016 /usr/local/bin/git-rev-parse
versus
102784 0.3641 /usr/lib/libsvn_subr-1.so.0.0.0
70235 0.2488 /usr/lib/libsvn_fs_fs-1.so.0.0.0
67081 0.2376 /usr/lib/libsvn_delta-1.so.0.0.0
848 0.0030 /usr/lib/libsvn_swig_perl-1.so.0.0.0
512 0.0018 /usr/lib/libsvn_ra_local-1.so.0.0.0
350 0.0012 /usr/lib/libsvn_fs-1.so.0.0.0
222 7.9e-04 /usr/lib/libsvn_repos-1.so.0.0.0
124 4.4e-04 /usr/lib/libsvn_ra-1.so.0.0.0
------------------------------------------------------------------------------------------------------------
4093890 64.3711 /home/good/vmlinux
906014 14.2459 /lib/libcrypto.so.0.9.8a
435744 6.8515 /lib/libc-2.4.so
158325 2.4895 /usr/lib/libz.so.1.2.3
139995 2.2012 /usr/local/bin/git-update-index
75322 1.1843 /nvidia
64349 1.0118 /usr/bin/oprofiled
52825 0.8306 /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
51930 0.8165 /usr/lib/libapr-1.so.0.2.2
42771 0.6725 /usr/local/bin/git-read-tree
37774 0.5939 /lib/ld-2.4.so
34761 0.5466 /usr/local/bin/git-write-tree
29560 0.4648 /usr/lib/libsvn_subr-1.so.0.0.0
28210 0.4436 /usr/lib/libaprutil-1.so.0.2.2
-----------------------------------------------------------------------------------------------------------------
2471826 32.8741 copy_page_range
375260 18.2903 unmap_vmas
574208 7.6367 release_pages
572189 7.6098 page_remove_rmap
233367 3.1037 free_pages_and_swap_cache
191051 2.5409 get_page_from_freelist
169058 2.2484 unlock_page
162027 2.1549 vm_normal_page
155691 2.0706 swap_info_get
136324 1.8130 swap_duplicate
119227 1.5857 page_fault
99729 1.3263 page_waitqueue
49288 0.6555 remove_exclusive_swap_page
39611 0.5268 do_wp_page
39142 0.5206 __wake_up_bit
34384 0.4573 __copy_from_user_ll
31111 0.4138 __handle_mm_fault
29990 0.3989 find_get_page
29682 0.3948 do_page_fault
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Nicolas Pitre @ 2006-06-14 19:25 UTC (permalink / raw)
To: Keith Packard; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <1150311567.30681.28.camel@neko.keithp.com>
On Wed, 14 Jun 2006, Keith Packard wrote:
> On Wed, 2006-06-14 at 11:18 -0700, Linus Torvalds wrote:
>
> > You don't _need_ to shuffle. As mentioned, it will only affect the
> > location of the data in the pack-file, which in turn will mostly matter
> > as an IO pattern thing, not anything really fundamental. If the pack-file
> > ends up caching well, the IO patterns obviously will never matter.
>
> Ok, sounds like shuffling isn't necessary; the only benefit packing
> gains me is to reduce the size of each directory in the object store;
> the process I follow is to construct blobs for every revision, then just
> use the sha1 values to construct an index for each commit. I never
> actually look at the blobs myself, so IO access patterns aren't
> relevant.
>
> Repacking after the import is completed should undo whatever horror show
> I've created in any case.
The only advantage of feeding object names from latest to oldest has to
do with the delta direction. In doing so the delta are backward such
that objects with deeper delta chain are further back in history and
this is what you want in the final pack for faster access to the latest
revision.
Of course the final repack will do that automatically, but only if you
use -a -f with git-repack. But when -f is not provided then already
deltified objects from other packs are copied as is without any delta
computation making the repack process lots faster. In that case it
might be preferable that the reuse of already deltified data is made of
backward delta which is the reason you might consider feeding object in
the prefered order up front.
Nicolas
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Linus Torvalds @ 2006-06-14 19:18 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1150311567.30681.28.camel@neko.keithp.com>
On Wed, 14 Jun 2006, Keith Packard wrote:
>
> Ok, sounds like shuffling isn't necessary; the only benefit packing
> gains me is to reduce the size of each directory in the object store;
There's actually a secondary benefit to packing that turned out to be much
bigger from a performance standpoint: the size benefit coupled with the
fact that it's all in one file ends up meaning that accessing packed
objects is _much_ faster than accessing individual files.
The Linux system call overhead is one of the lowest ones out there, but
it's still much bigger than just a function call, and doing a full
pathname walk and open/close is bigger yet. In contrast, if you access
lots of objects and they are all in a pack, you only end up doing one mmap
and a page fault for each 4kB entry, and that's it.
So packing has a large performance benefit outside of the actual disk use
one, and to some degree that performance benefit is then further magnified
by good locality (ie you get more effective objects per page fault), but
in your case that locality issue is secondary.
I assume that you never actually end up looking at the _contents_ of the
objects any more ever afterwards, because in a very real sense you're
really interested in the SHA1 names, right? All the latter phases of
parsecvs will just use the SHA1 names directly, and never actually even
open the data (packed or not).
So in that sense, you only care about the disksize and a much improved
directory walk from fewer files (until the repository has actually been
fully created, at which point a repack will do the right thing).
Linus
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Keith Packard @ 2006-06-14 18:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606141113130.5498@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
On Wed, 2006-06-14 at 11:18 -0700, Linus Torvalds wrote:
> You don't _need_ to shuffle. As mentioned, it will only affect the
> location of the data in the pack-file, which in turn will mostly matter
> as an IO pattern thing, not anything really fundamental. If the pack-file
> ends up caching well, the IO patterns obviously will never matter.
Ok, sounds like shuffling isn't necessary; the only benefit packing
gains me is to reduce the size of each directory in the object store;
the process I follow is to construct blobs for every revision, then just
use the sha1 values to construct an index for each commit. I never
actually look at the blobs myself, so IO access patterns aren't
relevant.
Repacking after the import is completed should undo whatever horror show
I've created in any case.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Repacking many disconnected blobs
From: Linus Torvalds @ 2006-06-14 18:52 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606141113130.5498@g5.osdl.org>
On Wed, 14 Jun 2006, Linus Torvalds wrote:
>
> You don't _need_ to shuffle. As mentioned, it will only affect the
> location of the data in the pack-file, which in turn will mostly matter
> as an IO pattern thing, not anything really fundamental. If the pack-file
> ends up caching well, the IO patterns obviously will never matter.
Actually, thinking about it more, the way you do things, shuffling
probably won't even help.
Why? Because you'll obviously have multiple files, and even if each file
were to be sorted "correctly", the access patterns from any global
standpoint won't really matter, becase you'd probably bounce back and
forth in the pack-file anyway.
So if anything, I would say
- just dump them into the packfile in whatever order is most convenient
- if you know that later phases will go through the objects and actually
use them (as opposed to just building trees out of their SHA1 values)
in some particular order, _that_ might be the ordering to use.
- in many ways, getting good delta chains is _much_ more important, since
"git repack -a -d" will re-use good deltas from a previous pack, but
will _not_ care about any ordering in the old pack. As well as
obviously improving the size of the temporary pack-files anyway.
I'll pontificate more if I can think of any other cases that might matter.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox