* Re: [PATCH] introduce inline is_same_sha1
From: Alex Riesen @ 2006-08-17 20:50 UTC (permalink / raw)
To: David Rientjes; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608171152110.22819@chino.corp.google.com>
On 8/17/06, David Rientjes <rientjes@google.com> wrote:
> Introduces global inline:
> hashcmp(const unsigned char *sha1, const unsigned char *sha2)
>
> Uses memcmp for comparison and returns the result based on the length of
> the hash name (a future runtime decision).
>
> Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
^ permalink raw reply
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Jakub Narebski @ 2006-08-17 20:00 UTC (permalink / raw)
To: git
In-Reply-To: <20060817194913.GD11477@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Thu, Aug 17, 2006 at 11:41:43AM +0200, Jakub Narebski wrote:
>> > Project list and OPML generation are now hooked into the list as
>> > "/summary" and "/opml".
>>
>> It would be better to use "/list" or "/projects", although empty or
>> undef or "/" action would work as well.
>>
>> Having both "/summary" (for projects list) and "summary" (for project
>> summary) is bad, bad idea.
>
> well, it was a little trick so that only one default action "summary"
> is needed. I have no strong feelings about it so any other name is
> good for me, too.
if (defined $project) { # with the patch that undef $project when empty
$action ||= "summary";
} else {
$action ||= "/projects_list"; # or simply "projects_list", or "/"
}
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Martin Waitz @ 2006-08-17 19:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ec1dis$823$3@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
hoi :)
On Thu, Aug 17, 2006 at 11:41:43AM +0200, Jakub Narebski wrote:
> > Project list and OPML generation are now hooked into the list as
> > "/summary" and "/opml".
>
> It would be better to use "/list" or "/projects", although empty or undef or
> "/" action would work as well.
>
> Having both "/summary" (for projects list) and "summary" (for project
> summary) is bad, bad idea.
well, it was a little trick so that only one default action "summary"
is needed. I have no strong feelings about it so any other name is
good for me, too.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Martin Waitz @ 2006-08-17 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk65815h1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]
hoi :)
On Wed, Aug 16, 2006 at 07:06:02PM -0700, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> > Allow to use the global action dispatcher for all actions by introducing
> > "/actions". If no project directory is given then a / is prepended to the
> > action and the normal dispatcher is called.
> > Project list and OPML generation are now hooked into the list as "/summary"
> > and "/opml".
> >
> > As "/" is not an allowed character in actions accepted through the CGI
> > parameters, it is still ensured that no normal action can be called without
> > giving a valid project directory.
> >
> > Signed-off-by: Martin Waitz <tali@admingilde.org>
> > ---
> > gitweb/gitweb.perl | 17 ++++++++---------
> > 1 files changed, 8 insertions(+), 9 deletions(-)
>
> You completely lost me. What are you trying to achieve here?
I just want to separate all the URL generation/parsing from the rest
of the code.
So I removed the opml/project list calls from the parsing code.
The target is to be able to be able to replace it without influencing
other parts of the code.
> I suspect this kind of funkies (and PATH_INFO) might be easier
> to do in mod_rewrite() outside gitweb, but that is probably just
> me.
Well, I think that the URL shown in the browser is one important
part of the user interface of a web page. So we should not rely
on the system administrator to implement it on his own.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use common parameter parsing and generation for "o", too.
From: Jakub Narebski @ 2006-08-17 19:34 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060817191300.GA11477@admingilde.org>
On Thu, Aug 17, 2006 at 21:13, Martin Waitz wrote:
> On Thu, Aug 17, 2006 at 11:35:18AM +0200, Jakub Narebski wrote:
>>> The "o" (list order) parameter was handled special.
>>> Now it is generated with the common href() function and parsed together with
>>> all other parameters.
>>
>> This was because "o" (sort table by) parameter was used only
>> in one place, and valid values of order parameter depends on
>> the place it is used.
>
> But I'd really like to have all the parameter parsing and generation
> code in one place.
>
> Perhaps we can agree that only the validation should be coupled with the
> actual user? E.g. use normal validate_input() for it and then check
> for actual values inside git_project_list (which is already done now).
The validate_input() function has too generic name and is too widely used:
it should be split into validate_ref() and validate_path(); perhaps "o"
should be validate with $order =~ m/^[a-zA-Z]$/
But I was thinking about moving parameter parsing to the "action" functions
which use them, the opposite of what you want to do...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: continue consolidation of URL generation.
From: Martin Waitz @ 2006-08-17 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voduk15sc.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
hoi :)
On Wed, Aug 16, 2006 at 06:59:15PM -0700, Junio C Hamano wrote:
> This is not about "further use href()".
Right.
I thought that it was needed in order to generate links to the
main project list page. But as this is only done via $home_link
this hunk is not needed. I just forgot to remove it again.
Should I send another patch or do you want to remove it yourself?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use common parameter parsing and generation for "o", too.
From: Martin Waitz @ 2006-08-17 19:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ec1d6q$823$2@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
hoi :)
On Thu, Aug 17, 2006 at 11:35:18AM +0200, Jakub Narebski wrote:
> > The "o" (list order) parameter was handled special.
> > Now it is generated with the common href() function and parsed together with
> > all other parameters.
>
> This was because "o" (sort table by) parameter was used only
> in one place, and valid values of order parameter depends on
> the place it is used.
But I'd really like to have all the parameter parsing and generation
code in one place.
Perhaps we can agree that only the validation should be coupled with the
actual user? E.g. use normal validate_input() for it and then check
for actual values inside git_project_list (which is already done now).
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Indentation fix.
From: Tilman Sauerbeck @ 2006-08-17 18:44 UTC (permalink / raw)
To: git
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
---
This trivial patch fixes some tab vs space mixup.
commit.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index 972d1b7..3b2f4a7 100644
--- a/commit.c
+++ b/commit.c
@@ -7,15 +7,15 @@ int save_commit_buffer = 1;
struct sort_node
{
/*
- * the number of children of the associated commit
- * that also occur in the list being sorted.
- */
+ * the number of children of the associated commit
+ * that also occur in the list being sorted.
+ */
unsigned int indegree;
/*
- * reference to original list item that we will re-use
- * on output.
- */
+ * reference to original list item that we will re-use
+ * on output.
+ */
struct commit_list * list_item;
};
--
1.4.2
^ permalink raw reply related
* Re: [PATCH 1/7] gitweb: Add support for per project git URLs
From: David Rientjes @ 2006-08-17 18:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Aneesh Kumar K.V
In-Reply-To: <11558064894129-git-send-email-jnareb@gmail.com>
On Thu, 17 Aug 2006, Jakub Narebski wrote:
> It is now possible for project to have individual clone/fetch URLs.
> They are provided in new file 'cloneurl' added below project's
> $GIT_DIR directory.
>
> If there is no cloneurl file, concatenation of git base URLs with
> project name is used.
>
> This is merge of Jakub Narebski and David Rientjes
> gitweb: Show project's git URL on summary page
> with Aneesh Kumar
> gitweb: Add support for cloneurl.
> gitweb: Support multiple clone urls
> patches.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: David Rientjes <rientjes@google.com>
^ permalink raw reply
* Re: [PATCH] introduce inline is_same_sha1
From: David Rientjes @ 2006-08-17 18:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0608170459if099fcane9d9e91a3fdac9e6@mail.gmail.com>
On Thu, 17 Aug 2006, Alex Riesen wrote:
> It is longer and negates all (like in "lots") previous callsites of memcmp.
> Are sure you didn't do a trivial typo somewhere?
>
> Why not just sha1cmp? And if you're aiming at hash-type independence,
> why not hashcmp?
>
hashcmp is a very good suggestion. Please ack the following.
David
---
Introduces global inline:
hashcmp(const unsigned char *sha1, const unsigned char *sha2)
Uses memcmp for comparison and returns the result based on the length of
the hash name (a future runtime decision).
Signed-off-by: David Rientjes <rientjes@google.com>
---
builtin-commit-tree.c | 2 +-
builtin-diff-stages.c | 2 +-
builtin-diff.c | 2 +-
builtin-pack-objects.c | 8 ++++----
builtin-show-branch.c | 4 ++--
builtin-unpack-objects.c | 4 ++--
builtin-update-index.c | 4 ++--
cache.h | 4 ++++
combine-diff.c | 4 ++--
commit.c | 2 +-
convert-objects.c | 2 +-
diff-lib.c | 2 +-
diff.c | 10 +++++-----
diffcore-break.c | 2 +-
diffcore-rename.c | 2 +-
dump-cache-tree.c | 2 +-
http-fetch.c | 6 +++---
http-push.c | 4 ++--
index-pack.c | 14 ++++++++------
merge-tree.c | 2 +-
object.c | 2 +-
pack-check.c | 6 +++---
pack-redundant.c | 14 +++++++-------
read-cache.c | 4 ++--
refs.c | 8 ++++----
send-pack.c | 2 +-
sha1_file.c | 16 ++++++++--------
sha1_name.c | 6 +++---
ssh-fetch.c | 2 +-
tree-diff.c | 3 +--
unpack-trees.c | 2 +-
31 files changed, 76 insertions(+), 71 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 9c98796..e2e690a 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -69,7 +69,7 @@ static int new_parent(int idx)
int i;
unsigned char *sha1 = parent_sha1[idx];
for (i = 0; i < idx; i++) {
- if (!memcmp(parent_sha1[i], sha1, 20)) {
+ if (!hashcmp(parent_sha1[i], sha1)) {
error("duplicate parent %s ignored", sha1_to_hex(sha1));
return 0;
}
diff --git a/builtin-diff-stages.c b/builtin-diff-stages.c
index 5960e08..70bb898 100644
--- a/builtin-diff-stages.c
+++ b/builtin-diff-stages.c
@@ -46,7 +46,7 @@ static void diff_stages(int stage1, int
else if (!two)
diff_addremove(&diff_options, '-', ntohl(one->ce_mode),
one->sha1, name, NULL);
- else if (memcmp(one->sha1, two->sha1, 20) ||
+ else if (hashcmp(one->sha1, two->sha1) ||
(one->ce_mode != two->ce_mode) ||
diff_options.find_copies_harder)
diff_change(&diff_options,
diff --git a/builtin-diff.c b/builtin-diff.c
index 40e5c96..874f773 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -69,7 +69,7 @@ static void stuff_change(struct diff_opt
struct diff_filespec *one, *two;
if (!is_null_sha1(old_sha1) && !is_null_sha1(new_sha1) &&
- !memcmp(old_sha1, new_sha1, 20))
+ !hashcmp(old_sha1, new_sha1))
return;
if (opt->reverse_diff) {
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 448461b..f19f0d6 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -441,7 +441,7 @@ static int locate_object_entry_hash(cons
memcpy(&ui, sha1, sizeof(unsigned int));
i = ui % object_ix_hashsz;
while (0 < object_ix[i]) {
- if (!memcmp(sha1, objects[object_ix[i]-1].sha1, 20))
+ if (!hashcmp(sha1, objects[object_ix[i] - 1].sha1))
return i;
if (++i == object_ix_hashsz)
i = 0;
@@ -607,7 +607,7 @@ static struct pbase_tree_cache *pbase_tr
*/
for (neigh = 0; neigh < 8; neigh++) {
ent = pbase_tree_cache[my_ix];
- if (ent && !memcmp(ent->sha1, sha1, 20)) {
+ if (ent && !hashcmp(ent->sha1, sha1)) {
ent->ref++;
return ent;
}
@@ -789,7 +789,7 @@ static void add_preferred_base(unsigned
return;
for (it = pbase_tree; it; it = it->next) {
- if (!memcmp(it->pcache.sha1, tree_sha1, 20)) {
+ if (!hashcmp(it->pcache.sha1, tree_sha1)) {
free(data);
return;
}
@@ -931,7 +931,7 @@ static struct object_entry **create_sort
static int sha1_sort(const struct object_entry *a, const struct object_entry *b)
{
- return memcmp(a->sha1, b->sha1, 20);
+ return hashcmp(a->sha1, b->sha1);
}
static struct object_entry **create_final_object_list(void)
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 95fbf77..18786f8 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -378,7 +378,7 @@ static int append_head_ref(const char *r
/* If both heads/foo and tags/foo exists, get_sha1 would
* get confused.
*/
- if (get_sha1(refname + ofs, tmp) || memcmp(tmp, sha1, 20))
+ if (get_sha1(refname + ofs, tmp) || hashcmp(tmp, sha1))
ofs = 5;
return append_ref(refname + ofs, sha1);
}
@@ -442,7 +442,7 @@ static int rev_is_head(char *head_path,
{
int namelen;
if ((!head_path[0]) ||
- (head_sha1 && sha1 && memcmp(head_sha1, sha1, 20)))
+ (head_sha1 && sha1 && hashcmp(head_sha1, sha1)))
return 0;
namelen = strlen(name);
if ((headlen < namelen) ||
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 63f4b8e..f0ae5c9 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -136,7 +136,7 @@ static void added_object(unsigned char *
struct delta_info *info;
while ((info = *p) != NULL) {
- if (!memcmp(info->base_sha1, sha1, 20)) {
+ if (!hashcmp(info->base_sha1, sha1)) {
*p = info->next;
p = &delta_list;
resolve_delta(type, data, size, info->delta, info->size);
@@ -292,7 +292,7 @@ int cmd_unpack_objects(int argc, const c
unpack_all();
SHA1_Update(&ctx, buffer, offset);
SHA1_Final(sha1, &ctx);
- if (memcmp(fill(20), sha1, 20))
+ if (hashcmp(fill(20), sha1))
die("final sha1 did not match");
use(20);
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 9f0cf28..5dd91af 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -378,7 +378,7 @@ static int unresolve_one(const char *pat
ret = -1;
goto free_return;
}
- if (!memcmp(ce_2->sha1, ce_3->sha1, 20) &&
+ if (!hashcmp(ce_2->sha1, ce_3->sha1) &&
ce_2->ce_mode == ce_3->ce_mode) {
fprintf(stderr, "%s: identical in both, skipping.\n",
path);
@@ -460,7 +460,7 @@ static int do_reupdate(int ac, const cha
old = read_one_ent(NULL, head_sha1,
ce->name, ce_namelen(ce), 0);
if (old && ce->ce_mode == old->ce_mode &&
- !memcmp(ce->sha1, old->sha1, 20)) {
+ !hashcmp(ce->sha1, old->sha1)) {
free(old);
continue; /* unchanged */
}
diff --git a/cache.h b/cache.h
index c738299..f99254b 100644
--- a/cache.h
+++ b/cache.h
@@ -214,6 +214,10 @@ static inline int is_null_sha1(const uns
{
return !memcmp(sha1, null_sha1, 20);
}
+static inline int hashcmp(const unsigned char *sha1, const unsigned char *sha2)
+{
+ return memcmp(sha1, sha2, 20);
+}
int git_mkstemp(char *path, size_t n, const char *template);
diff --git a/combine-diff.c b/combine-diff.c
index ce063b4..0682acd 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -688,8 +688,8 @@ static void show_patch_diff(struct combi
for (i = 0; i < num_parent; i++) {
int j;
for (j = 0; j < i; j++) {
- if (!memcmp(elem->parent[i].sha1,
- elem->parent[j].sha1, 20)) {
+ if (!hashcmp(elem->parent[i].sha1,
+ elem->parent[j].sha1)) {
reuse_combine_diff(sline, cnt, i, j);
break;
}
diff --git a/commit.c b/commit.c
index 972d1b7..d17451f 100644
--- a/commit.c
+++ b/commit.c
@@ -123,7 +123,7 @@ static int commit_graft_pos(const unsign
while (lo < hi) {
int mi = (lo + hi) / 2;
struct commit_graft *graft = commit_graft[mi];
- int cmp = memcmp(sha1, graft->sha1, 20);
+ int cmp = hashcmp(sha1, graft->sha1);
if (!cmp)
return mi;
if (cmp < 0)
diff --git a/convert-objects.c b/convert-objects.c
index 168771e..4e7ff75 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -39,7 +39,7 @@ static struct entry *lookup_entry(unsign
while (low < high) {
int next = (low + high) / 2;
struct entry *n = convert[next];
- int cmp = memcmp(sha1, n->old_sha1, 20);
+ int cmp = hashcmp(sha1, n->old_sha1);
if (!cmp)
return n;
if (cmp < 0) {
diff --git a/diff-lib.c b/diff-lib.c
index 116b5a9..3e4b3b9 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -215,7 +215,7 @@ static int show_modified(struct rev_info
}
oldmode = old->ce_mode;
- if (mode == oldmode && !memcmp(sha1, old->sha1, 20) &&
+ if (mode == oldmode && !hashcmp(sha1, old->sha1) &&
!revs->diffopt.find_copies_harder)
return 0;
diff --git a/diff.c b/diff.c
index 7a238d0..da7cca1 100644
--- a/diff.c
+++ b/diff.c
@@ -1140,7 +1140,7 @@ static int work_tree_matches(const char
if ((lstat(name, &st) < 0) ||
!S_ISREG(st.st_mode) || /* careful! */
ce_match_stat(ce, &st, 0) ||
- memcmp(sha1, ce->sha1, 20))
+ hashcmp(sha1, ce->sha1))
return 0;
/* we return 1 only when we can stat, it is a regular file,
* stat information matches, and sha1 recorded in the cache
@@ -1168,7 +1168,7 @@ static struct sha1_size_cache *locate_si
while (last > first) {
int cmp, next = (last + first) >> 1;
e = sha1_size_cache[next];
- cmp = memcmp(e->sha1, sha1, 20);
+ cmp = hashcmp(e->sha1, sha1);
if (!cmp)
return e;
if (cmp < 0) {
@@ -1579,7 +1579,7 @@ static void run_diff(struct diff_filepai
;
}
- if (memcmp(one->sha1, two->sha1, 20)) {
+ if (hashcmp(one->sha1, two->sha1)) {
int abbrev = o->full_index ? 40 : DEFAULT_ABBREV;
len += snprintf(msg + len, sizeof(msg) - len,
@@ -2098,7 +2098,7 @@ int diff_unmodified_pair(struct diff_fil
* dealing with a change.
*/
if (one->sha1_valid && two->sha1_valid &&
- !memcmp(one->sha1, two->sha1, sizeof(one->sha1)))
+ !hashcmp(one->sha1, two->sha1))
return 1; /* no change */
if (!one->sha1_valid && !two->sha1_valid)
return 1; /* both look at the same file on the filesystem. */
@@ -2237,7 +2237,7 @@ static void diff_resolve_rename_copy(voi
if (!p->status)
p->status = DIFF_STATUS_RENAMED;
}
- else if (memcmp(p->one->sha1, p->two->sha1, 20) ||
+ else if (hashcmp(p->one->sha1, p->two->sha1) ||
p->one->mode != p->two->mode)
p->status = DIFF_STATUS_MODIFIED;
else {
diff --git a/diffcore-break.c b/diffcore-break.c
index ed0e14c..acb18db 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -56,7 +56,7 @@ static int should_break(struct diff_file
return 0; /* leave symlink rename alone */
if (src->sha1_valid && dst->sha1_valid &&
- !memcmp(src->sha1, dst->sha1, 20))
+ !hashcmp(src->sha1, dst->sha1))
return 0; /* they are the same */
if (diff_populate_filespec(src, 0) || diff_populate_filespec(dst, 0))
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 0ec488a..ef23901 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -101,7 +101,7 @@ static int is_exact_match(struct diff_fi
int contents_too)
{
if (src->sha1_valid && dst->sha1_valid &&
- !memcmp(src->sha1, dst->sha1, 20))
+ !hashcmp(src->sha1, dst->sha1))
return 1;
if (!contents_too)
return 0;
diff --git a/dump-cache-tree.c b/dump-cache-tree.c
index 1ccaf51..1f73f1e 100644
--- a/dump-cache-tree.c
+++ b/dump-cache-tree.c
@@ -33,7 +33,7 @@ static int dump_cache_tree(struct cache_
}
else {
dump_one(it, pfx, "");
- if (memcmp(it->sha1, ref->sha1, 20) ||
+ if (hashcmp(it->sha1, ref->sha1) ||
ref->entry_count != it->entry_count ||
ref->subtree_nr != it->subtree_nr) {
dump_one(ref, pfx, "#(ref) ");
diff --git a/http-fetch.c b/http-fetch.c
index 7f07d2a..d1f74b4 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -301,7 +301,7 @@ static void finish_object_request(struct
unlink(obj_req->tmpfile);
return;
}
- if (memcmp(obj_req->sha1, obj_req->real_sha1, 20)) {
+ if (hashcmp(obj_req->sha1, obj_req->real_sha1)) {
unlink(obj_req->tmpfile);
return;
}
@@ -1070,7 +1070,7 @@ static int fetch_object(struct alt_base
int ret = 0;
struct object_request *obj_req = object_queue_head;
- while (obj_req != NULL && memcmp(obj_req->sha1, sha1, 20))
+ while (obj_req != NULL && hashcmp(obj_req->sha1, sha1))
obj_req = obj_req->next;
if (obj_req == NULL)
return error("Couldn't find request for %s in the queue", hex);
@@ -1109,7 +1109,7 @@ #endif
} else if (obj_req->zret != Z_STREAM_END) {
corrupt_object_found++;
ret = error("File %s (%s) corrupt", hex, obj_req->url);
- } else if (memcmp(obj_req->sha1, obj_req->real_sha1, 20)) {
+ } else if (hashcmp(obj_req->sha1, obj_req->real_sha1)) {
ret = error("File %s has bad hash", hex);
} else if (obj_req->rename < 0) {
ret = error("unable to write sha1 filename %s",
diff --git a/http-push.c b/http-push.c
index 2bd9845..4849779 100644
--- a/http-push.c
+++ b/http-push.c
@@ -745,7 +745,7 @@ static void finish_request(struct transf
SHA1_Final(request->real_sha1, &request->c);
if (request->zret != Z_STREAM_END) {
unlink(request->tmpfile);
- } else if (memcmp(request->obj->sha1, request->real_sha1, 20)) {
+ } else if (hashcmp(request->obj->sha1, request->real_sha1)) {
unlink(request->tmpfile);
} else {
request->rename =
@@ -2416,7 +2416,7 @@ int main(int argc, char **argv)
if (!ref->peer_ref)
continue;
- if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
+ if (!hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
if (push_verbosely || 1)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
diff --git a/index-pack.c b/index-pack.c
index b20659c..2063ae9 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -82,7 +82,7 @@ static void parse_pack_header(void)
SHA1_Init(&ctx);
SHA1_Update(&ctx, pack_base, pack_size - 20);
SHA1_Final(sha1, &ctx);
- if (memcmp(sha1, pack_base + pack_size - 20, 20))
+ if (hashcmp(sha1, pack_base + pack_size - 20))
die("packfile '%s' SHA1 mismatch", pack_name);
}
@@ -189,7 +189,7 @@ static int find_delta(const unsigned cha
struct delta_entry *delta = &deltas[next];
int cmp;
- cmp = memcmp(base_sha1, delta->base_sha1, 20);
+ cmp = hashcmp(base_sha1, delta->base_sha1);
if (!cmp)
return next;
if (cmp < 0) {
@@ -210,9 +210,11 @@ static int find_deltas_based_on_sha1(con
if (first < 0)
return -1;
- while (first > 0 && !memcmp(deltas[first-1].base_sha1, base_sha1, 20))
+ while (first > 0 && !hashcmp(deltas[first - 1].base_sha1,
+ base_sha1))
--first;
- while (last < end && !memcmp(deltas[last+1].base_sha1, base_sha1, 20))
+ while (last < end && !hashcmp(deltas[last + 1].base_sha1,
+ base_sha1))
++last;
*first_index = first;
*last_index = last;
@@ -278,7 +280,7 @@ static int compare_delta_entry(const voi
{
const struct delta_entry *delta_a = a;
const struct delta_entry *delta_b = b;
- return memcmp(delta_a->base_sha1, delta_b->base_sha1, 20);
+ return hashcmp(delta_a->base_sha1, delta_b->base_sha1);
}
static void parse_pack_objects(void)
@@ -350,7 +352,7 @@ static int sha1_compare(const void *_a,
{
struct object_entry *a = *(struct object_entry **)_a;
struct object_entry *b = *(struct object_entry **)_b;
- return memcmp(a->sha1, b->sha1, 20);
+ return hashcmp(a->sha1, b->sha1);
}
static void write_index_file(const char *index_name, unsigned char *sha1)
diff --git a/merge-tree.c b/merge-tree.c
index 7cf00be..c2e9a86 100644
--- a/merge-tree.c
+++ b/merge-tree.c
@@ -152,7 +152,7 @@ static int same_entry(struct name_entry
{
return a->sha1 &&
b->sha1 &&
- !memcmp(a->sha1, b->sha1, 20) &&
+ !hashcmp(a->sha1, b->sha1) &&
a->mode == b->mode;
}
diff --git a/object.c b/object.c
index b5d8ed4..fdcfff7 100644
--- a/object.c
+++ b/object.c
@@ -58,7 +58,7 @@ struct object *lookup_object(const unsig
i = hashtable_index(sha1);
while ((obj = obj_hash[i]) != NULL) {
- if (!memcmp(sha1, obj->sha1, 20))
+ if (!hashcmp(sha1, obj->sha1))
break;
i++;
if (i == obj_hash_size)
diff --git a/pack-check.c b/pack-check.c
index 3a62e1b..04c6c00 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -29,10 +29,10 @@ static int verify_packfile(struct packed
pack_base = p->pack_base;
SHA1_Update(&ctx, pack_base, pack_size - 20);
SHA1_Final(sha1, &ctx);
- if (memcmp(sha1, (char *) pack_base + pack_size - 20, 20))
+ if (hashcmp(sha1, (unsigned char *)pack_base + pack_size - 20))
return error("Packfile %s SHA1 mismatch with itself",
p->pack_name);
- if (memcmp(sha1, (char *) index_base + index_size - 40, 20))
+ if (hashcmp(sha1, (unsigned char *)index_base + index_size - 40))
return error("Packfile %s SHA1 mismatch with idx",
p->pack_name);
@@ -135,7 +135,7 @@ int verify_pack(struct packed_git *p, in
SHA1_Init(&ctx);
SHA1_Update(&ctx, index_base, index_size - 20);
SHA1_Final(sha1, &ctx);
- if (memcmp(sha1, (char *) index_base + index_size - 20, 20))
+ if (hashcmp(sha1, (unsigned char *)index_base + index_size - 20))
ret = error("Packfile index for %s SHA1 mismatch",
p->pack_name);
diff --git a/pack-redundant.c b/pack-redundant.c
index 92a09ed..edb5524 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -139,7 +139,7 @@ static inline struct llist_item *llist_i
l = (hint == NULL) ? list->front : hint;
while (l) {
- int cmp = memcmp(l->sha1, sha1, 20);
+ int cmp = hashcmp(l->sha1, sha1);
if (cmp > 0) { /* we insert before this entry */
return llist_insert(list, prev, sha1);
}
@@ -162,7 +162,7 @@ redo_from_start:
l = (hint == NULL) ? list->front : hint;
prev = NULL;
while (l) {
- int cmp = memcmp(l->sha1, sha1, 20);
+ int cmp = hashcmp(l->sha1, sha1);
if (cmp > 0) /* not in list, since sorted */
return prev;
if(!cmp) { /* found */
@@ -256,7 +256,7 @@ static void cmp_two_packs(struct pack_li
while (p1_off <= p1->pack->index_size - 3 * 20 &&
p2_off <= p2->pack->index_size - 3 * 20)
{
- int cmp = memcmp(p1_base + p1_off, p2_base + p2_off, 20);
+ int cmp = hashcmp(p1_base + p1_off, p2_base + p2_off);
/* cmp ~ p1 - p2 */
if (cmp == 0) {
p1_hint = llist_sorted_remove(p1->unique_objects,
@@ -351,16 +351,16 @@ static size_t sizeof_union(struct packed
{
size_t ret = 0;
int p1_off, p2_off;
- char *p1_base, *p2_base;
+ unsigned char *p1_base, *p2_base;
p1_off = p2_off = 256 * 4 + 4;
- p1_base = (char *)p1->index_base;
- p2_base = (char *)p2->index_base;
+ p1_base = (unsigned char *)p1->index_base;
+ p2_base = (unsigned char *)p2->index_base;
while (p1_off <= p1->index_size - 3 * 20 &&
p2_off <= p2->index_size - 3 * 20)
{
- int cmp = memcmp(p1_base + p1_off, p2_base + p2_off, 20);
+ int cmp = hashcmp(p1_base + p1_off, p2_base + p2_off);
/* cmp ~ p1 - p2 */
if (cmp == 0) {
ret++;
diff --git a/read-cache.c b/read-cache.c
index 6bec833..b6982ea 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -60,7 +60,7 @@ static int ce_compare_data(struct cache_
if (fd >= 0) {
unsigned char sha1[20];
if (!index_fd(sha1, fd, st, 0, NULL))
- match = memcmp(sha1, ce->sha1, 20);
+ match = hashcmp(sha1, ce->sha1);
/* index_fd() closed the file descriptor already */
}
return match;
@@ -744,7 +744,7 @@ static int verify_hdr(struct cache_heade
SHA1_Init(&c);
SHA1_Update(&c, hdr, size - 20);
SHA1_Final(sha1, &c);
- if (memcmp(sha1, (char *) hdr + size - 20, 20))
+ if (hashcmp(sha1, (unsigned char *)hdr + size - 20))
return error("bad index file sha1 signature");
return 0;
}
diff --git a/refs.c b/refs.c
index 86ef916..17cd0ce 100644
--- a/refs.c
+++ b/refs.c
@@ -281,7 +281,7 @@ static struct ref_lock *verify_lock(stru
unlock_ref(lock);
return NULL;
}
- if (memcmp(lock->old_sha1, old_sha1, 20)) {
+ if (hashcmp(lock->old_sha1, old_sha1)) {
error("Ref %s is at %s but expected %s", lock->ref_file,
sha1_to_hex(lock->old_sha1), sha1_to_hex(old_sha1));
unlock_ref(lock);
@@ -411,7 +411,7 @@ int write_ref_sha1(struct ref_lock *lock
if (!lock)
return -1;
- if (!lock->force_write && !memcmp(lock->old_sha1, sha1, 20)) {
+ if (!lock->force_write && !hashcmp(lock->old_sha1, sha1)) {
unlock_ref(lock);
return 0;
}
@@ -475,7 +475,7 @@ int read_ref_at(const char *ref, unsigne
die("Log %s is corrupt.", logfile);
if (get_sha1_hex(rec + 41, sha1))
die("Log %s is corrupt.", logfile);
- if (memcmp(logged_sha1, sha1, 20)) {
+ if (hashcmp(logged_sha1, sha1)) {
tz = strtoul(tz_c, NULL, 10);
fprintf(stderr,
"warning: Log %s has gap after %s.\n",
@@ -489,7 +489,7 @@ int read_ref_at(const char *ref, unsigne
else {
if (get_sha1_hex(rec + 41, logged_sha1))
die("Log %s is corrupt.", logfile);
- if (memcmp(logged_sha1, sha1, 20)) {
+ if (hashcmp(logged_sha1, sha1)) {
tz = strtoul(tz_c, NULL, 10);
fprintf(stderr,
"warning: Log %s unexpectedly ended on %s.\n",
diff --git a/send-pack.c b/send-pack.c
index 43e10b0..f7c0cfc 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -265,7 +265,7 @@ static int send_pack(int in, int out, in
char old_hex[60], *new_hex;
if (!ref->peer_ref)
continue;
- if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
+ if (!hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
if (verbose)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
diff --git a/sha1_file.c b/sha1_file.c
index 18dece4..04f7f94 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -485,10 +485,10 @@ int use_packed_git(struct packed_git *p)
/* Check if the pack file matches with the index file.
* this is cheap.
*/
- if (memcmp((char*)(p->index_base) + p->index_size - 40,
- (char *) p->pack_base + p->pack_size - 20,
- 20)) {
-
+ if (hashcmp((unsigned char *)(p->index_base) +
+ p->index_size - 40,
+ (unsigned char *)p->pack_base +
+ p->pack_size - 20)) {
die("packfile %s does not match index.", p->pack_name);
}
}
@@ -643,7 +643,7 @@ int check_sha1_signature(const unsigned
SHA1_Update(&c, header, 1+sprintf(header, "%s %lu", type, size));
SHA1_Update(&c, map, size);
SHA1_Final(real_sha1, &c);
- return memcmp(sha1, real_sha1, 20) ? -1 : 0;
+ return hashcmp(sha1, real_sha1) ? -1 : 0;
}
void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
@@ -941,7 +941,7 @@ int check_reuse_pack_delta(struct packed
ptr = unpack_object_header(p, ptr, kindp, sizep);
if (*kindp != OBJ_DELTA)
goto done;
- memcpy(base, (char *) p->pack_base + ptr, 20);
+ memcpy(base, (unsigned char *) p->pack_base + ptr, 20);
status = 0;
done:
unuse_packed_git(p);
@@ -1206,7 +1206,7 @@ int find_pack_entry_one(const unsigned c
do {
int mi = (lo + hi) / 2;
- int cmp = memcmp((char *) index + (24 * mi) + 4, sha1, 20);
+ int cmp = hashcmp((unsigned char *)index + (24 * mi) + 4, sha1);
if (!cmp) {
e->offset = ntohl(*((unsigned int *) ((char *) index + (24 * mi))));
memcpy(e->sha1, sha1, 20);
@@ -1715,7 +1715,7 @@ int write_sha1_from_fd(const unsigned ch
unlink(tmpfile);
return error("File %s corrupted", sha1_to_hex(sha1));
}
- if (memcmp(sha1, real_sha1, 20)) {
+ if (hashcmp(sha1, real_sha1)) {
unlink(tmpfile);
return error("File %s has bad hash", sha1_to_hex(sha1));
}
diff --git a/sha1_name.c b/sha1_name.c
index f567454..e9eb6ce 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -84,7 +84,7 @@ static int find_short_packed_object(int
int cmp;
nth_packed_object_sha1(p, mid, now);
- cmp = memcmp(match, now, 20);
+ cmp = hashcmp(match, now);
if (!cmp) {
first = mid;
break;
@@ -106,7 +106,7 @@ static int find_short_packed_object(int
memcpy(found_sha1, now, 20);
found++;
}
- else if (memcmp(found_sha1, now, 20)) {
+ else if (hashcmp(found_sha1, now)) {
found = 2;
break;
}
@@ -144,7 +144,7 @@ static int find_unique_short_object(int
return 0;
}
/* Both have unique ones -- do they match? */
- if (memcmp(packed_sha1, unpacked_sha1, 20))
+ if (hashcmp(packed_sha1, unpacked_sha1))
return SHORT_NAME_AMBIGUOUS;
memcpy(sha1, packed_sha1, 20);
return 0;
diff --git a/ssh-fetch.c b/ssh-fetch.c
index 0b89df6..b006c5c 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -67,7 +67,7 @@ int fetch(unsigned char *sha1)
signed char remote;
struct object_list *temp;
- if (memcmp(sha1, in_transit->item->sha1, 20)) {
+ if (hashcmp(sha1, in_transit->item->sha1)) {
/* we must have already fetched it to clean the queue */
return has_sha1_file(sha1) ? 0 : -1;
}
diff --git a/tree-diff.c b/tree-diff.c
index 916f489..7e2f4f0 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -39,8 +39,7 @@ static int compare_tree_entry(struct tre
show_entry(opt, "+", t2, base);
return 1;
}
- if (!opt->find_copies_harder &&
- !memcmp(sha1, sha2, 20) && mode1 == mode2)
+ if (!opt->find_copies_harder && !hashcmp(sha1, sha2) && mode1 == mode2)
return 0;
/*
diff --git a/unpack-trees.c b/unpack-trees.c
index 43ed124..467d994 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -417,7 +417,7 @@ static int same(struct cache_entry *a, s
if (!a && !b)
return 1;
return a->ce_mode == b->ce_mode &&
- !memcmp(a->sha1, b->sha1, 20);
+ !hashcmp(a->sha1, b->sha1);
}
--
1.4.2.gd4ba-dirty
^ permalink raw reply related
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-17 18:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <9e4733910608171103j545a7fd5x2b61b97376de04be@mail.gmail.com>
On Thu, 17 Aug 2006, Jon Smirl wrote:
> On 8/17/06, Nicolas Pitre <nico@cam.org> wrote:
> > We're streaving for optimal data storage here so don't be afraid to use
> > one of the available types for an "object stream" object. Because when
> > you think of it, the deflating of multiple objects into a single zlib
> > stream can be applied to all object types not only deltas. If ever
> > deflating many blobs into one zlib stream is dimmed worth it then the
> > encoding will already be ready for it. Also you can leverage existing
> > code to write headers, etc.
>
> Here are two more case that need to be accounted for in the packs.
>
> 1) If you zip something and it gets bigger. We need an entry that just
> stores the object without it being zipped. Zipping jpegs or mpegs will
> likely make them significantly bigger. Or does zlib like already
> detect this case and do a null compression?
zlib appears to do the right thing here.
> 2) If you delta something and the delta is bigger than the object
> being deltaed. The delta code should detect this and store the full
> object instead of the delta. Again jpegs and mpegs will trigger this.
> You may even want to say that the delta has to be smaller than 80% of
> the full object.
I'd invite you to read te try_delta() code in
[builtin-]builtin-pack-objects.c. You might find that we're already way
more agressive than that with rather simple heuristics that have been
tweaked and tuned for over a year now. The commit logs for that file
(before the rename to builtin-pack-objects.c) is also quite
enlightening.
Nicolas
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-17 18:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Shawn Pearce, git
In-Reply-To: <9e4733910608171022w25886d13ka40e5752fec4680b@mail.gmail.com>
On Thu, 17 Aug 2006, Jon Smirl wrote:
> On 8/17/06, Nicolas Pitre <nico@cam.org> wrote:
> > Nah. The only overhead for a server to feed an "old" pack format from a
> > "new" pack file is to inflate and deflate some data. That is not _that_
> > costly.
>
> It is costly because the Mozilla pack is going to inflate from 295MB
> to 845MB. It will take you much longer to download an extra 500MB than
> upgrading your client would take.
I didn't say it isn't costly. I said that it isn't _that_ costly to the
point of bringing down a server.
Nicolas
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-17 18:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0608171323330.11359@localhost.localdomain>
On 8/17/06, Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 17 Aug 2006, Jon Smirl wrote:
>
> > Is there a pack format version number built into the server procotol?
> > If not there needs to be one. When there is a mismatch with the server
> > pack version the client should simply display an error requesting an
> > upgrade of the client software.
>
> There is a pack version number. Reception of an unknown pack already
> produces an error:
>
> if (!pack_version_ok(hdr->hdr_version))
> die("unknown pack file version %d", ntohl(hdr->hdr_version));
>
> That will occur really early in a pull or clone when using the native
> protocol.
Can this be fixed so that if the pack protocol coming from the server
is greater than the one handled by the client. they client gets a nice
hint about upgrading?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-17 18:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0608171233370.11359@localhost.localdomain>
On 8/17/06, Nicolas Pitre <nico@cam.org> wrote:
> We're streaving for optimal data storage here so don't be afraid to use
> one of the available types for an "object stream" object. Because when
> you think of it, the deflating of multiple objects into a single zlib
> stream can be applied to all object types not only deltas. If ever
> deflating many blobs into one zlib stream is dimmed worth it then the
> encoding will already be ready for it. Also you can leverage existing
> code to write headers, etc.
Here are two more case that need to be accounted for in the packs.
1) If you zip something and it gets bigger. We need an entry that just
stores the object without it being zipped. Zipping jpegs or mpegs will
likely make them significantly bigger. Or does zlib like already
detect this case and do a null compression?
2) If you delta something and the delta is bigger than the object
being deltaed. The delta code should detect this and store the full
object instead of the delta. Again jpegs and mpegs will trigger this.
You may even want to say that the delta has to be smaller than 80% of
the full object.
Shawn is planning on looking into true dictionary based compression.
That will generate even more types inside of a pack. If dictionary
compression works out full text search can be added with a little more
overhead. True dictionary based compression has the potential to go
even smaller than the current 280MB. The optimal way to do this is for
each pack to contain it's own dictionary.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] gitweb: bugfix: git_print_page_path() needs the hash base
From: Luben Tuikov @ 2006-08-17 17:39 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
If a file F exists in branch B, but doesn't exist
in master branch, then blob_plain needs the hash base in
order to properly get the file. The hash base is passed
on symbolically so we still preserve the "latest" quality
of the link presented by git_print_page_path().
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
[-- Attachment #2: 2795696785-p1.patch --]
[-- Type: application/octet-stream, Size: 3264 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 36d3082..bb77b55 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1175,12 +1175,18 @@ sub git_print_header_div {
sub git_print_page_path {
my $name = shift;
my $type = shift;
+ my $hb = shift;
if (!defined $name) {
print "<div class=\"page_path\"><b>/</b></div>\n";
} elsif (defined $type && $type eq 'blob') {
- print "<div class=\"page_path\"><b>" .
- $cgi->a({-href => href(action=>"blob_plain", file_name=>$file_name)}, esc_html($name)) . "</b><br/></div>\n";
+ print "<div class=\"page_path\"><b>";
+ if (defined $hb) {
+ print $cgi->a({-href => href(action=>"blob_plain", hash_base=>$hb, file_name=>$file_name)}, esc_html($name));
+ } else {
+ print $cgi->a({-href => href(action=>"blob_plain", file_name=>$file_name)}, esc_html($name));
+ }
+ print "</b><br/></div>\n";
} else {
print "<div class=\"page_path\"><b>" . esc_html($name) . "</b><br/></div>\n";
}
@@ -1868,7 +1874,7 @@ sub git_blame2 {
" | " . $cgi->a({-href => href(action=>"blame", file_name=>$file_name)}, "head");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
- git_print_page_path($file_name, $ftype);
+ git_print_page_path($file_name, $ftype, $hash_base);
my @rev_color = (qw(light2 dark2));
my $num_colors = scalar(@rev_color);
my $current_color = 0;
@@ -1922,7 +1928,7 @@ sub git_blame {
" | " . $cgi->a({-href => href(action=>"blame", file_name=>$file_name)}, "head");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
- git_print_page_path($file_name, 'blob');
+ git_print_page_path($file_name, 'blob', $hash_base);
print "<div class=\"page_body\">\n";
print <<HTML;
<table class="blame">
@@ -2085,7 +2091,7 @@ sub git_blob {
"<br/><br/></div>\n" .
"<div class=\"title\">$hash</div>\n";
}
- git_print_page_path($file_name, "blob");
+ git_print_page_path($file_name, "blob", $hash_base);
print "<div class=\"page_body\">\n";
my $nr;
while (my $line = <$fd>) {
@@ -2135,7 +2141,7 @@ sub git_tree {
if (defined $file_name) {
$base = esc_html("$file_name/");
}
- git_print_page_path($file_name, 'tree');
+ git_print_page_path($file_name, 'tree', $hash_base);
print "<div class=\"page_body\">\n";
print "<table cellspacing=\"0\">\n";
my $alternate = 0;
@@ -2332,7 +2338,7 @@ sub git_blobdiff {
"<br/><br/></div>\n" .
"<div class=\"title\">$hash vs $hash_parent</div>\n";
}
- git_print_page_path($file_name, "blob");
+ git_print_page_path($file_name, "blob", $hash_base);
print "<div class=\"page_body\">\n" .
"<div class=\"diff_info\">blob:" .
$cgi->a({-href => href(action=>"blob", hash=>$hash_parent, hash_base=>$hash_base, file_name=>($file_parent || $file_name))}, $hash_parent) .
@@ -2502,7 +2508,7 @@ sub git_history {
if (defined $hash) {
$ftype = git_get_type($hash);
}
- git_print_page_path($file_name, $ftype);
+ git_print_page_path($file_name, $ftype, $hash_base);
open my $fd, "-|",
$GIT, "rev-list", "--full-history", $hash_base, "--", $file_name;
--
1.4.2.gdb98
^ permalink raw reply related
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-17 17:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Shawn Pearce, git
In-Reply-To: <9e4733910608171017k628ef754s4fcd075d60aaf062@mail.gmail.com>
On Thu, 17 Aug 2006, Jon Smirl wrote:
> Is there a pack format version number built into the server procotol?
> If not there needs to be one. When there is a mismatch with the server
> pack version the client should simply display an error requesting an
> upgrade of the client software.
There is a pack version number. Reception of an unknown pack already
produces an error:
if (!pack_version_ok(hdr->hdr_version))
die("unknown pack file version %d", ntohl(hdr->hdr_version));
That will occur really early in a pull or clone when using the native
protocol.
> Git should be designed for forward evolution, not infinite backward
> compatibility. It is easy to upgrade your client to support the new
> protocol. The protocol just needs to ensure that the client reliably
> gets an error about the need to upgrade.
>
> Forward evolution implies that a client is able to work with older
> servers, but not the inverse, that new servers have to work with old
> clients.
And still, if we really wanted, the server could have the ability to
stream an old pack format by simply inflating the grouped objects and
deflating them individually all on the fly, which is not necessarily
that costly. But it might still be a good idea to simply have the
ability to generate both formats and make the grouped deltas the default
only after a while.
Nicolas
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-17 17:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0608171220260.11359@localhost.localdomain>
On 8/17/06, Nicolas Pitre <nico@cam.org> wrote:
> Nah. The only overhead for a server to feed an "old" pack format from a
> "new" pack file is to inflate and deflate some data. That is not _that_
> costly.
It is costly because the Mozilla pack is going to inflate from 295MB
to 845MB. It will take you much longer to download an extra 500MB than
upgrading your client would take.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-17 17:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jon Smirl, git
In-Reply-To: <20060817040719.GC18500@spearce.org>
On Thu, 17 Aug 2006, Shawn Pearce wrote:
> I'm going to try to integrate this into core GIT this weekend.
> My current idea is to make use of the OBJ_EXT type flag to add
> an extended header field behind the length which describes the
> "chunk" as being a delta chain compressed in one zlib stream.
> I'm not overly concerned about saving lots of space in the header
> here as it looks like we're winning a huge amount of pack space,
> so the extended header will probably itself be a couple of bytes.
> This keeps the shorter reserved types free for other great ideas. :)
We're streaving for optimal data storage here so don't be afraid to use
one of the available types for an "object stream" object. Because when
you think of it, the deflating of multiple objects into a single zlib
stream can be applied to all object types not only deltas. If ever
deflating many blobs into one zlib stream is dimmed worth it then the
encoding will already be ready for it. Also you can leverage existing
code to write headers, etc.
I'd suggest you use OBJ_GROUP = 0 as a new primary object type. Then
the "size" field in the header could then become the number of objects
that are included in the group. Most of the time that will fit in the
low 4 bits of the first header byte, but if there is more than 15
grouped objects then more bits can be used on the following byte.
Anyway so far all the code to generate and parse that is already there.
If ever there is a need for more extensions that could be prefixed with
a pure zero byte (an object group with a zero object count which is
distinguishable from a real group).
Then, having the number of grouped objects, you just have to list the
usual headers for those objects, which are their type and inflated size
just like regular object headers, including the base sha1 for deltas.
Again you already have code to produce and parse those.
And finally just append the objects payload in a single deflated stream.
This way the reading of an object from a group can be optimized if the
object data is located at the beginning of the stream such that you only
need to inflate the amount of bytes leading to the desired data
(possibly caching those for further delta replaying), inflate
the needed data for the desired object and then ignoring the remaining
of the stream.
Nicolas
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-17 17:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.63.0608171738490.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On 8/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Aug 2006, Jon Smirl wrote:
>
> > On 8/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > At least, the delta-chains should be limited by size (_not_ by number of
> > > deltas: you can have huge deltas, and if you have to unpack 5 huge deltas
> > > before getting to the huge delta you really need, it takes really long).
> >
> > This is not an obvious conclusion.
>
> The big win is bought by having _one_ zlib stream for multiple deltas,
> right?
>
> So, everytime you want to access the _last_ delta in the chain, you unpack
> _all_ of them. This quite obvious conclusion is obviously your reason to
> propose two packs, one for the archive of "old" objects, and one for the
> "new" objects.
Do some measurements, the IO vs CPU time trade off is way in favor of
eliminating the IO. It really doesn't take very much CPU to unpack the
delta chain.
The two pack proprosal was not about reducing the delta chain length;
they are reverse deltas, the newest version is always at the front.
Two packs are used to avoid repacking the 280MB pack when you do a
repack command. It takes 2-3 hours to repack 280MB. Even if if you
just copy the old pack to the new it take 30 minutes to do all of the
IO.
> > As for public servers there is an immediate win in shifting to the new
> > pack format. Three hour downloads vs one hour, plus the bandwidth
> > bills. Are the tools smart enough to say this is a newer pack format,
> > upgrade? It takes far less than two hours to upgrade your git install.
>
> Have you thought about a non-upgraded client? The server has to repack in
> that case, and if the client wants a clone, you might not even have the
> time to kiss your server good-bye before it goes belly up.
Is there a pack format version number built into the server procotol?
If not there needs to be one. When there is a mismatch with the server
pack version the client should simply display an error requesting an
upgrade of the client software.
Git should be designed for forward evolution, not infinite backward
compatibility. It is easy to upgrade your client to support the new
protocol. The protocol just needs to ensure that the client reliably
gets an error about the need to upgrade.
Forward evolution implies that a client is able to work with older
servers, but not the inverse, that new servers have to work with old
clients.
> There is an obvious choice here as to how fast people would upgrade their
> servers.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Johannes Schindelin @ 2006-08-17 17:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0608171220260.11359@localhost.localdomain>
Hi,
On Thu, 17 Aug 2006, Nicolas Pitre wrote:
> On Thu, 17 Aug 2006, Johannes Schindelin wrote:
>
> > On Thu, 17 Aug 2006, Jon Smirl wrote:
> >
> > > On 8/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > At least, the delta-chains should be limited by size (_not_ by number of
> > > > deltas: you can have huge deltas, and if you have to unpack 5 huge deltas
> > > > before getting to the huge delta you really need, it takes really long).
> > >
> > > This is not an obvious conclusion.
> >
> > The big win is bought by having _one_ zlib stream for multiple deltas,
> > right?
> >
> > So, everytime you want to access the _last_ delta in the chain, you unpack
> > _all_ of them.
>
> This is the case whether deltas are separately deflated or not.
Oh, now I get it! The delta chain is comprised of exactly those deltas
which are needed to reconstruct a certain object from another object which
was stored undeltified in the pack.
Now it makes sense to me that they could be bundled before being deflated.
In the pack-index, the objects of that delta-chain could just point to
the delta-chain object. Which has a mini-index in its extended header.
Or did I misunderstand again?
Ciao,
Dscho
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-17 16:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.63.0608171738490.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 17 Aug 2006, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 17 Aug 2006, Jon Smirl wrote:
>
> > On 8/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > At least, the delta-chains should be limited by size (_not_ by number of
> > > deltas: you can have huge deltas, and if you have to unpack 5 huge deltas
> > > before getting to the huge delta you really need, it takes really long).
> >
> > This is not an obvious conclusion.
>
> The big win is bought by having _one_ zlib stream for multiple deltas,
> right?
>
> So, everytime you want to access the _last_ delta in the chain, you unpack
> _all_ of them.
This is the case whether deltas are separately deflated or not.
> This quite obvious conclusion is obviously your reason to
> propose two packs, one for the archive of "old" objects, and one for the
> "new" objects.
Old objects are usually further down the delta chain and also stored
further from the beginning of the pack. Hence "new" objects could still
have quick access since even if a delta chain is all in the same zlib
stream, it is likely that inflating the whole of the zlib stream to get
"new" objects won't be necessary, just like it is done now where only
the needed deltas are inflated.
> > As for public servers there is an immediate win in shifting to the new
> > pack format. Three hour downloads vs one hour, plus the bandwidth
> > bills. Are the tools smart enough to say this is a newer pack format,
> > upgrade? It takes far less than two hours to upgrade your git install.
>
> Have you thought about a non-upgraded client? The server has to repack in
> that case, and if the client wants a clone, you might not even have the
> time to kiss your server good-bye before it goes belly up.
Nah. The only overhead for a server to feed an "old" pack format from a
"new" pack file is to inflate and deflate some data. That is not _that_
costly.
Nicolas
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Johannes Schindelin @ 2006-08-17 15:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <9e4733910608170736y4863e0ebr55c6c822ae548cca@mail.gmail.com>
Hi,
On Thu, 17 Aug 2006, Jon Smirl wrote:
> On 8/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > At least, the delta-chains should be limited by size (_not_ by number of
> > deltas: you can have huge deltas, and if you have to unpack 5 huge deltas
> > before getting to the huge delta you really need, it takes really long).
>
> This is not an obvious conclusion.
The big win is bought by having _one_ zlib stream for multiple deltas,
right?
So, everytime you want to access the _last_ delta in the chain, you unpack
_all_ of them. This quite obvious conclusion is obviously your reason to
propose two packs, one for the archive of "old" objects, and one for the
"new" objects.
> As for public servers there is an immediate win in shifting to the new
> pack format. Three hour downloads vs one hour, plus the bandwidth
> bills. Are the tools smart enough to say this is a newer pack format,
> upgrade? It takes far less than two hours to upgrade your git install.
Have you thought about a non-upgraded client? The server has to repack in
that case, and if the client wants a clone, you might not even have the
time to kiss your server good-bye before it goes belly up.
There is an obvious choice here as to how fast people would upgrade their
servers.
Ciao,
Dscho
^ permalink raw reply
* gitweb: Support for snapshot
From: Aneesh Kumar K.V @ 2006-08-17 15:29 UTC (permalink / raw)
To: git
This adds snapshort support in gitweb. To enable one need to
set gitweb.snapshot = true in the config file.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@hp.com>
---
gitweb/gitweb.perl | 41 +++++++++++++++++++++++++++++++++++++----
1 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 04282fa..52653a0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -15,6 +15,7 @@ use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
+use File::Basename qw(basename);
binmode STDOUT, ':utf8';
our $cgi = new CGI;
@@ -175,6 +176,7 @@ my %actions = (
"tag" => \&git_tag,
"tags" => \&git_tags,
"tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
);
$action = 'summary' if (!defined($action));
@@ -1320,6 +1322,7 @@ sub git_difftree_body {
sub git_shortlog_body {
# uses global variable $project
my ($revlist, $from, $to, $refs, $extra) = @_;
+ my $have_snapshot = git_get_project_config_bool('snapshot');
$from = 0 unless defined $from;
$to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
@@ -1344,8 +1347,11 @@ sub git_shortlog_body {
print "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
- "</td>\n" .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
+ if ($have_snapshot) {
+ print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
+ }
+ print "</td>\n" .
"</tr>\n";
}
if (defined $extra) {
@@ -2112,6 +2118,29 @@ sub git_tree {
git_footer_html();
}
+sub git_snapshot {
+
+ if (!defined $hash) {
+ $hash = git_get_head_hash($project);
+ }
+
+ my $filename = basename($project) . "-$hash.tar.gz";
+
+ print $cgi->header(-type => 'application/x-tar',
+ -content-encoding => 'gzip',
+ '-content-disposition' => "inline; filename=\"$filename\"",
+ -status => '200 OK');
+
+ open my $fd, "-|", "$GIT tar-tree $hash \'$project\' | gzip" or
+ die_error(undef, "Execute git-tar-tree failed.");
+ binmode STDOUT, ':raw';
+ print <$fd>;
+ binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
+ close $fd;
+
+
+}
+
sub git_log {
my $head = git_get_head_hash($project);
if (!defined $hash) {
@@ -2206,6 +2235,7 @@ sub git_commit {
}
my $refs = git_get_references();
my $ref = format_ref_marker($refs, $co{'id'});
+ my $have_snapshot = git_get_project_config_bool('snapshot');
my $formats_nav = '';
if (defined $file_name && defined $co{'parent'}) {
my $parent = $co{'parent'};
@@ -2241,8 +2271,11 @@ sub git_commit {
"<td class=\"sha1\">" .
$cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash), class => "list"}, $co{'tree'}) .
"</td>" .
- "<td class=\"link\">" . $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash)}, "tree") .
- "</td>" .
+ "<td class=\"link\">" . $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash)}, "tree");
+ if ($have_snapshot) {
+ print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$hash)}, "snapshot");
+ }
+ print "</td>" .
"</tr>\n";
my $parents = $co{'parents'};
foreach my $par (@$parents) {
--
1.4.2.rc1.g83e1-dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Carl Worth @ 2006-08-17 15:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, git
In-Reply-To: <7vk65815h1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Wed, 16 Aug 2006 19:06:02 -0700, Junio C Hamano wrote:
>
> You completely lost me. What are you trying to achieve here?
Presumably the goal is to take better advantage of the hierarchical
namespace provided with the path component of the URL before dropping
to the query string.
> I suspect this kind of funkies (and PATH_INFO) might be easier
> to do in mod_rewrite() outside gitweb, but that is probably just
> me.
Personally, I disagree, (at least as far as PATH_INFO---my feelings
aren't as strong for the action parameters).
A current problem I have with git is the difficulty of publishing a
new repository to the world. With our current setup on
freedesktop.org, for example, I have to publish 3 separate URLs
depending on how users might decide to interact with my repository,
(one for gitweb browsing and two separate URLs for doing git
clone/fetch/pull over either git: or http:). Much of that can now be
fixed with configuration changes on our server---but anything git can
do to simplify the amount of configuration is definitely appreciated.
-Carl
PS. A secondary problem is the difficulty of publishing a new
branch. But if I can get the 3 URLs above down to 1, then I could
probably live with the user having to figure out how to combine the
repository URL with the branch name, (in different ways depending on
what the user is doing).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-17 14:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.63.0608171003020.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On 8/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> At least, the delta-chains should be limited by size (_not_ by number of
> deltas: you can have huge deltas, and if you have to unpack 5 huge deltas
> before getting to the huge delta you really need, it takes really long).
This is not an obvious conclusion. Reducing our pack from 845MB to
292MB eliminates a huge amount of IO. All of the work I am doing with
this pack has been totally IO bound. The CPU time to get from one
delta to another is minor compared to the IO time increase if you
break the chains up. Each time you break the chain you have to store a
full copy of the file, the IO increase from doing this out weighs the
CPU time reduction.
I would use a two pack model. One pack holds the 292MB archive and the
second pack is made from recent changes. They can both be the same
format since the chains in the second pack won't be very long. We
might want to put a flag into an archive pack that tells git-repack
not to touch it by default.
As for public servers there is an immediate win in shifting to the new
pack format. Three hour downloads vs one hour, plus the bandwidth
bills. Are the tools smart enough to say this is a newer pack format,
upgrade? It takes far less than two hours to upgrade your git install.
--
Jon Smirl
jonsmirl@gmail.com
^ 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