* Re: GPF in index-pack
From: Sergey Vlasov @ 2006-08-06 13:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <20060806040848.GF20565@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 4855 bytes --]
On Sun, 6 Aug 2006 00:08:48 -0400 Shawn Pearce wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 8/5/06, Shawn Pearce <spearce@spearce.org> wrote:
> > >Jon Smirl <jonsmirl@gmail.com> wrote:
[...]
> > >> Why does resolve_delta in index-pack.c need to be recursive? Is there
> > >> a better way to code that routine? If it mmaps the file that uses 1GB
> > >> address space, why does it need another 1.5GB to build an index?
> > >
> > >Probably the easiest way to code the routine. Delta depth is
> > >bounded; in the fast-import.c that I sent out last night I hardcoded
> > >it to 10, which is (I believe) the default for GIT. So long as that
> > >routine is recursive only along a single delta chain the recursion
> > >depth won't be very high and shouldn't be the problem.
> >
> > When I put index-pack in gdb at the seg fault, resolve_delta had
> > recursed more than 20,000 times. I stopped looking after that.
>
> Ouch. I'm not familiar with this code, but looking at right now its
> also not entirely obviously what its recursing for. Plus dinner
> is trying to be burned on the grill, so my attention is on that
> more than on GIT. :-)
git-pack-objects never creates a pack file with duplicate objects,
therefore git-index-pack was never tested on such pack files - no wonder
that it breaks.
The case of patch revert (A -> B -> A again) is probably the problem -
your dumb pack generator will probably write this:
A
B (delta based on A)
A (delta based on B)
git-index-pack will first unpack the first copy of A, then notice that A
is used as a delta base for B and apply the delta, then it will find the
second copy of A and apply that delta, and then it will find B again...
Please try the patch at the end of this message - it should help to
avoid the infinite recursion in git-index-pack. However, I'm not sure
that other git parts won't do something bad when they encounter an index
with duplicate sha1 entries (and git-index-pack cannot remove these
duplicates, because the number of index entries must match the pack
header).
> > >> I had a prior 400MB pack file built with fast-import that I was able
> > >> to index ok.
> > >
> > >Dumb luck? Maybe that had no duplicates while this one does?
> >
> > Is there a git command to list the sha1's in a pack that doesn't have
> > an index? I could sort it, sort it unqiue, and then diff the outputs.
git-index-pack :)
(git-unpack-objects will also have all sha1 values at the end, but the
side effect of unpacking all objects to separate files is probably not
what you want to get.)
> Not that I know of. Packs themselves don't have the SHA1 values and
> getting them from a pack without an index is a painful exercise as
> you don't know where the base of an object resides within the pack
> when you need it to generate the object's raw content to determine
> its ID.
Yes, this is a problem. git-unpack-objects can unpack all objects in a
single pass, but only because it temporarily saves all deltas which
cannot be resolved yet, and can read back objects which it has written
before. git-index-pack needs to work without modifying the object
database, so it works in two passes:
/*
* First pass:
* - find locations of all objects;
* - calculate SHA1 of all non-delta objects;
* - remember base SHA1 for all deltas.
*/
/*
* Second pass:
* - for all non-delta objects, look if it is used as a base for
* deltas;
* - if used as a base, uncompress the object and apply all deltas,
* recursively checking if the resulting object is used as a base
* for some more deltas.
*/
-----------------------------------------------------------------------
From: Sergey Vlasov <vsu@altlinux.ru>
Date: Sun, 6 Aug 2006 17:28:29 +0400
Subject: [PATCH] git-index-pack: Avoid infinite recursion if the pack has duplicate objects
Although git-pack-objects never creates packs which contain the same
object more than once, other tools may be not so careful, so add a check
to prevents infinite recursion of resolve_delta() for such packs.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
index-pack.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index b39953d..a8e3b1f 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -257,6 +257,13 @@ static void resolve_delta(struct delta_e
unsigned long next_obj_offset;
int j, first, last;
+ /*
+ * Do nothing if this delta was resolved earlier (this can happen if
+ * the pack contains duplicate objects for some reason).
+ */
+ if (obj->real_type != OBJ_DELTA)
+ return;
+
obj->real_type = type;
delta_data = unpack_raw_entry(obj->offset, &delta_type,
&delta_size, base_sha1,
--
1.4.2.rc3.g23aa
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply related
* [PATCH] gitweb: check if HTTP_ACCEPT is really set
From: Matthias Lederhofer @ 2006-08-06 13:55 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
If the client does not send Accept: HTTP_ACCEPT is undefined and there
is a warning:
Use of uninitialized value in pattern match (m//) at line 862.
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f85dc7d..1f4b0f5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -859,7 +859,7 @@ sub git_header_html {
# 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
# we have to do this because MSIE sometimes globs '*/*', pretending to
# support xhtml+xml but choking when it gets what it asked for.
- if ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) {
+ if (defined $cgi->http('HTTP_ACCEPT') && $cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) {
$content_type = 'application/xhtml+xml';
} else {
$content_type = 'text/html';
--
1.4.2.rc3.g2f52
^ permalink raw reply related
* [PATCH] gitweb: fix commitdiff for root commits
From: Jakub Narebski @ 2006-08-06 14:14 UTC (permalink / raw)
To: git, Matthias Lederhofer
After changing all "-|" open invocations to list form, commitdiff for
initial commit (without parent) got broken; it returned incorrectly
empty patch earlier. Use '--root' option to git-diff-tree for initial
(root) commit.
No checking for empty $hash_parent in git_commitdiff_plain -- we rely
on gitweb to give correct parameters for commitdiff_plain action.
Noticed by Matthias Lederhofer (matled).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Patch based on 'next' branch (234416bff6c426a9abaaacef80ba3679c0ce8f39)
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d0672cd..bbea21a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2109,7 +2109,7 @@ sub git_commitdiff {
die_error(undef, "Unknown commit object");
}
if (!defined $hash_parent) {
- $hash_parent = $co{'parent'};
+ $hash_parent = $co{'parent'} || '--root';
}
open my $fd, "-|", $GIT, "diff-tree", '-r', $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
--
1.4.1.1
^ permalink raw reply related
* Rejuvenation for you!
From: Lamont Chan @ 2006-08-06 16:03 UTC (permalink / raw)
To: geogirb
Hi there!
Want to live forever? Or at least, longer than you was to? Here is the way to trick Mother Nature!
Its widely known, that there is a special hormone, which is responsible for the rejuvenation and growth of human tissues. Its produced by your anterior pituitary gland in the brain, and as you grow older its produced less and less by your body.
But what if bring this Human Growth Hormone from somewhere outside and into your body? The scientists has found a formula for a rejuvenation course, so dont wait and find the solution of the eternal problem here!
http://r6b.welguide.com/hgh
^ permalink raw reply
* Re: fast-import and unique objects.
From: Jon Smirl @ 2006-08-06 15:53 UTC (permalink / raw)
To: git, Shawn Pearce
In-Reply-To: <9e4733910608060532w51fca2c0r8038828df0d41eeb@mail.gmail.com>
On 8/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> This model has a lot of object duplication. I generated 949,305
> revisions, but only 754,165 are unique. I'll modify my code to build a
> hash of the objects it has seen and then not send the duplicates to
> fast-import. Those 195,140 duplicated objects may be what is tripping
> index-pack up.
New run is finished with duplicate removal.
Time to run is unchanged, still 2hrs. Run time is IO bound not CPU.
Pack file is 845MB instead of 934MB.
git-index-pack works now, it takes 4 CPU minutes to run.
Index file is 18MB.
So it looks like the first stage code is working. Next I need to
modify cvs2svn to keep track of the sha-1 through it's sorting process
instead of file:revision.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] gitweb: ignore lines from diff-tree which do not match the expected format
From: Matthias Lederhofer @ 2006-08-06 15:55 UTC (permalink / raw)
To: git
The sha1 on the first line of git diff-tree -r --root sha1 does not
match the expected format and produces warnings.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
gitweb/gitweb.perl | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1f4b0f5..b0da0ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1772,7 +1772,9 @@ sub git_tree {
my $alternate = 0;
foreach my $line (@entries) {
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
- $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/;
+ if (!($line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/)) {
+ next;
+ }
my $t_mode = $1;
my $t_type = $2;
my $t_hash = $3;
@@ -2163,7 +2165,9 @@ sub git_commitdiff {
foreach my $line (@difftree) {
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
- $line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/;
+ if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/)) {
+ next;
+ }
my $from_mode = $1;
my $to_mode = $2;
my $from_id = $3;
--
1.4.1.gfd699
^ permalink raw reply related
* [PATCH] gitweb: Skip nonmatching lines in difftree output, consistently
From: Jakub Narebski @ 2006-08-06 15:59 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <20060806155505.GA9548@moooo.ath.cx>
This fixes error for commitdiff on root commit (without parents).
Noticed-by: Matthias Lederhofer (matled)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bbea21a..78ef13d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1983,7 +1983,7 @@ sub git_commit {
foreach my $line (@difftree) {
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
- if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
+ if ($line !~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/) {
next;
}
my $from_mode = $1;
@@ -2156,7 +2156,9 @@ sub git_commitdiff {
foreach my $line (@difftree) {
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
- $line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/;
+ if ($line !~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/) {
+ next;
+ }
my $from_mode = $1;
my $to_mode = $2;
my $from_id = $3;
@@ -2230,7 +2232,9 @@ sub git_commitdiff_plain {
print "---\n\n";
foreach my $line (@difftree) {
- $line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/;
+ if ($line !~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/) {
+ next;
+ }
my $from_id = $3;
my $to_id = $4;
my $status = $5;
--
1.4.1.1
^ permalink raw reply related
* Re: [PATCH] gitweb: Skip nonmatching lines in difftree output, consistently
From: Jakub Narebski @ 2006-08-06 16:01 UTC (permalink / raw)
To: git
In-Reply-To: <11548799921728-git-send-email-jnareb@gmail.com>
Jakub Narebski wrote:
> This fixes error for commitdiff on root commit (without parents).
>
> Noticed-by: Matthias Lederhofer (matled)
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
This is an alternate patch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC] gitweb test script
From: Matthias Lederhofer @ 2006-08-06 16:51 UTC (permalink / raw)
To: git
Perhaps this script has a place in the git repository. Creating some automated
tests at least checking for warnings should be easy too. This should work from
the git repository and makes gitweb use .git as repository. At the moment it
still needs the git binary to be in the path already to find the top repository
directory.
This could also be extended for automated tests. Here is an example how this
could look like (currently this does not test much of gitweb):
#!/bin/sh
die() {
echo "$0: $*" >&2
exit 1
}
cleanup() {
[ -e "$TMP" ] && rm "$TMP"
}
test() {
echo "test: $@"
"$gitweb" "$@" > /dev/null 2> "$TMP"
if [ ! -s "$TMP" ]; then
return
fi
echo "========== ERRORS =========="
cat "$TMP"
echo "============================"
}
gitweb="./`git rev-parse --show-cdup`/t/gitweb.sh"
TMP=""
trap cleanup EXIT
TMP="`mktemp`" || die mktemp failed
# repository overview
test
# summary
test p=.git
# commitdiff
# initial commit
test p=.git a=commitdiff \
h=e83c5163316f89bfbde7d9ab23ca2e25604af290
# some other commit
test p=.git a=commitdiff \
h=5a716826a6f7f209777f344143cdd9e4f2903097
# merge commit withouth specified parent
test p=.git a=commitdiff \
h=e190bc55431d906b8c70dc07f8b6d823721f12c9
# merge commit with specified parent
test p=.git a=commitdiff \
h=e190bc55431d906b8c70dc07f8b6d823721f12c9 \
hp=360204c324ca9178e2bcb4d75f3986201f8ac7e1
---
t/gitweb.sh | 29 +++++++++++++++++++++++++++++
t/gitweb_config.perl | 4 ++++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/t/gitweb.sh b/t/gitweb.sh
new file mode 100755
index 0000000..b0dff26
--- /dev/null
+++ b/t/gitweb.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+# this script runs gitweb.perl from the shell having .git as repository
+# command line parameters are used as query string
+
+TOPDIR="`pwd``git rev-parse --show-cdup`"
+if [ ! -e "$TOPDIR/git" ]; then
+ echo "$0: You haven't built things yet, have you?" >&2
+ exit 1
+fi
+
+export PATH="$TOPDIR:$PATH"
+export GIT_EXEC_PATH="$TOPDIR"
+
+# cgi environment
+export GATEWAY_INTERFACE=CGI/1.1
+export REQUEST_METHOD=GET
+QUERY_STRING=""
+if [ $# -gt 0 ]; then
+ QUERY_STRING="$1"
+ shift
+fi
+while [ $# -gt 0 ]; do
+ QUERY_STRING="$QUERY_STRING;$1"
+ shift
+done
+export QUERY_STRING
+
+export GITWEB_CONFIG="$TOPDIR/t/gitweb_config.perl"
+exec "$TOPDIR/gitweb/gitweb.perl"
diff --git a/t/gitweb_config.perl b/t/gitweb_config.perl
new file mode 100644
index 0000000..5c245ff
--- /dev/null
+++ b/t/gitweb_config.perl
@@ -0,0 +1,4 @@
+$projectroot = "./".qx(git rev-parse --show-cdup);
+chomp($projectroot);
+$projects_list = $projectroot;
+$GIT = $projectroot.'/git';
--
1.4.1.gfd699
^ permalink raw reply related
* [PATCH] gitweb: fix commitdiff_plain for root commits
From: Matthias Lederhofer @ 2006-08-06 17:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11548799921728-git-send-email-jnareb@gmail.com>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
See [PATCH] gitweb: fix commitdiff for root commits from Jakub:
> No checking for empty $hash_parent in git_commitdiff_plain -- we
> rely on gitweb to give correct parameters for commitdiff_plain
> action.
I think we should always check the input and prevent any warnings.
This patch is on top of Jakubs patch, mine just did the if (!($line =~
m/..)) { next; } to be consistent with the other ifs.
---
gitweb/gitweb.perl | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d9648a0..b3bfc6b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2200,6 +2200,13 @@ sub git_commitdiff {
sub git_commitdiff_plain {
mkdir($git_temp, 0700);
+ my %co = git_read_commit($hash);
+ if (!%co) {
+ die_error(undef, "Unknown commit object");
+ }
+ if (!defined $hash_parent) {
+ $hash_parent = $co{'parent'} || '--root';
+ }
open my $fd, "-|", $GIT, "diff-tree", '-r', $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
@@ -2221,7 +2228,6 @@ sub git_commitdiff_plain {
}
print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"git-$hash.patch\"");
- my %co = git_read_commit($hash);
my %ad = date_str($co{'author_epoch'}, $co{'author_tz'});
my $comment = $co{'comment'};
print "From: $co{'author'}\n" .
--
1.4.1.gfd699
^ permalink raw reply related
* Re: fast-import and unique objects.
From: Shawn Pearce @ 2006-08-06 18:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608060853ua0eabc1w9b35b8414d3c9bae@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]
Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> >This model has a lot of object duplication. I generated 949,305
> >revisions, but only 754,165 are unique. I'll modify my code to build a
> >hash of the objects it has seen and then not send the duplicates to
> >fast-import. Those 195,140 duplicated objects may be what is tripping
> >index-pack up.
>
> New run is finished with duplicate removal.
>
> Time to run is unchanged, still 2hrs. Run time is IO bound not CPU.
> Pack file is 845MB instead of 934MB.
> git-index-pack works now, it takes 4 CPU minutes to run.
> Index file is 18MB.
I'm attaching a new version of fast-import.c which generates the
index, and does duplicate removal. However I think that it might
be slightly faster for you to do the duplicate removal in Python
as it saves the user-kernel-user copy of the file data. Even so,
this new version should save you those 4 CPU minutes as the index
will be generated from the in-memory SHA1s rather than needing to
recompute them.
I've changed the calling convention:
- It now takes the pack's base name as its first parameter. It
appends ".pack" and ".idx" to form the actual file names its
writing to.
- It expects an estimated object count as its second parameter.
In your case this would be something around 760000. This tells
it how large of an object table to allocate, with each entry
being 24 bytes + 1 pointer (28 or 32 bytes). Overshooting
this number will cause it to degrade by allocating one
overflow entry at a time from malloc.
So the new version should take about 20 MB of memory and should
produce a valid pack and index in the same time as it does only
the pack now. Plus it won't generate duplicates.
> So it looks like the first stage code is working. Next I need to
> modify cvs2svn to keep track of the sha-1 through it's sorting process
> instead of file:revision.
When you get down to tree writing and commit writing we might want
to do something similiar with the trees and commits. I can modify
fast-import to also store those off into a pack.
--
Shawn.
[-- Attachment #2: fast-import.c --]
[-- Type: text/x-csrc, Size: 8018 bytes --]
#include "builtin.h"
#include "cache.h"
#include "object.h"
#include "blob.h"
#include "delta.h"
#include "pack.h"
#include "csum-file.h"
static int max_depth = 10;
static unsigned long object_count;
static unsigned long duplicate_count;
static unsigned long packoff;
static unsigned long overflow_count;
static int packfd;
static int current_depth;
static void *lastdat;
static unsigned long lastdatlen;
static unsigned char lastsha1[20];
static unsigned char packsha1[20];
struct object_entry
{
struct object_entry *next;
unsigned long offset;
unsigned char sha1[20];
};
struct overflow_object_entry
{
struct overflow_object_entry *next;
struct object_entry oe;
};
struct object_entry *pool_start;
struct object_entry *pool_next;
struct object_entry *pool_end;
struct overflow_object_entry *overflow;
struct object_entry *table[1 << 16];
static struct object_entry* new_object(unsigned char *sha1)
{
if (pool_next != pool_end) {
struct object_entry *e = pool_next++;
memcpy(e->sha1, sha1, sizeof(e->sha1));
return e;
} else {
struct overflow_object_entry *e;
e = xmalloc(sizeof(struct overflow_object_entry));
e->next = overflow;
memcpy(e->oe.sha1, sha1, sizeof(e->oe.sha1));
overflow = e;
overflow_count++;
return &e->oe;
}
}
static struct object_entry* insert_object(unsigned char *sha1)
{
unsigned int h = sha1[0] << 8 | sha1[1];
struct object_entry *e = table[h];
struct object_entry *p = 0;
while (e) {
if (!memcmp(sha1, e->sha1, sizeof(e->sha1)))
return e;
p = e;
e = e->next;
}
e = new_object(sha1);
e->next = 0;
e->offset = 0;
if (p)
p->next = e;
else
table[h] = e;
return e;
}
static ssize_t yread(int fd, void *buffer, size_t length)
{
ssize_t ret = 0;
while (ret < length) {
ssize_t size = xread(fd, (char *) buffer + ret, length - ret);
if (size < 0) {
return size;
}
if (size == 0) {
return ret;
}
ret += size;
}
return ret;
}
static ssize_t ywrite(int fd, void *buffer, size_t length)
{
ssize_t ret = 0;
while (ret < length) {
ssize_t size = xwrite(fd, (char *) buffer + ret, length - ret);
if (size < 0) {
return size;
}
if (size == 0) {
return ret;
}
ret += size;
}
return ret;
}
static unsigned long encode_header(enum object_type type, unsigned long size, unsigned char *hdr)
{
int n = 1;
unsigned char c;
if (type < OBJ_COMMIT || type > OBJ_DELTA)
die("bad type %d", type);
c = (type << 4) | (size & 15);
size >>= 4;
while (size) {
*hdr++ = c | 0x80;
c = size & 0x7f;
size >>= 7;
n++;
}
*hdr = c;
return n;
}
static void write_blob(void *dat, unsigned long datlen)
{
z_stream s;
void *out, *delta;
unsigned char hdr[64];
unsigned long hdrlen, deltalen;
if (lastdat && current_depth < max_depth) {
delta = diff_delta(lastdat, lastdatlen,
dat, datlen,
&deltalen, 0);
} else
delta = 0;
memset(&s, 0, sizeof(s));
deflateInit(&s, zlib_compression_level);
if (delta) {
current_depth++;
s.next_in = delta;
s.avail_in = deltalen;
hdrlen = encode_header(OBJ_DELTA, deltalen, hdr);
if (ywrite(packfd, hdr, hdrlen) != hdrlen)
die("Can't write object header: %s", strerror(errno));
if (ywrite(packfd, lastsha1, sizeof(lastsha1)) != sizeof(lastsha1))
die("Can't write object base: %s", strerror(errno));
packoff += hdrlen + sizeof(lastsha1);
} else {
current_depth = 0;
s.next_in = dat;
s.avail_in = datlen;
hdrlen = encode_header(OBJ_BLOB, datlen, hdr);
if (ywrite(packfd, hdr, hdrlen) != hdrlen)
die("Can't write object header: %s", strerror(errno));
packoff += hdrlen;
}
s.avail_out = deflateBound(&s, s.avail_in);
s.next_out = out = xmalloc(s.avail_out);
while (deflate(&s, Z_FINISH) == Z_OK)
/* nothing */;
deflateEnd(&s);
if (ywrite(packfd, out, s.total_out) != s.total_out)
die("Failed writing compressed data %s", strerror(errno));
packoff += s.total_out;
free(out);
if (delta)
free(delta);
}
static void init_pack_header()
{
const char* magic = "PACK";
unsigned long version = 2;
unsigned long zero = 0;
version = htonl(version);
if (ywrite(packfd, (char*)magic, 4) != 4)
die("Can't write pack magic: %s", strerror(errno));
if (ywrite(packfd, &version, 4) != 4)
die("Can't write pack version: %s", strerror(errno));
if (ywrite(packfd, &zero, 4) != 4)
die("Can't write 0 object count: %s", strerror(errno));
packoff = 4 * 3;
}
static void fixup_header_footer()
{
SHA_CTX c;
char hdr[8];
unsigned long cnt;
char *buf;
size_t n;
if (lseek(packfd, 0, SEEK_SET) != 0)
die("Failed seeking to start: %s", strerror(errno));
SHA1_Init(&c);
if (yread(packfd, hdr, 8) != 8)
die("Failed reading header: %s", strerror(errno));
SHA1_Update(&c, hdr, 8);
cnt = htonl(object_count);
SHA1_Update(&c, &cnt, 4);
if (ywrite(packfd, &cnt, 4) != 4)
die("Failed writing object count: %s", strerror(errno));
buf = xmalloc(128 * 1024);
for (;;) {
n = xread(packfd, buf, 128 * 1024);
if (n <= 0)
break;
SHA1_Update(&c, buf, n);
}
free(buf);
SHA1_Final(packsha1, &c);
if (ywrite(packfd, packsha1, sizeof(packsha1)) != sizeof(packsha1))
die("Failed writing pack checksum: %s", strerror(errno));
}
static int oecmp (const void *_a, const void *_b)
{
struct object_entry *a = *((struct object_entry**)_a);
struct object_entry *b = *((struct object_entry**)_b);
return memcmp(a->sha1, b->sha1, sizeof(a->sha1));
}
static void write_index(const char *idx_name)
{
struct sha1file *f;
struct object_entry **idx, **c, **last;
struct object_entry *e;
struct overflow_object_entry *o;
unsigned int array[256];
int i;
/* Build the sorted table of object IDs. */
idx = xmalloc(object_count * sizeof(struct object_entry*));
c = idx;
for (e = pool_start; e != pool_next; e++)
*c++ = e;
for (o = overflow; o; o = o->next)
*c++ = &o->oe;
last = idx + object_count;
qsort(idx, object_count, sizeof(struct object_entry*), oecmp);
/* Generate the fan-out array. */
c = idx;
for (i = 0; i < 256; i++) {
struct object_entry **next = c;;
while (next < last) {
if ((*next)->sha1[0] != i)
break;
next++;
}
array[i] = htonl(next - idx);
c = next;
}
f = sha1create("%s", idx_name);
sha1write(f, array, 256 * sizeof(int));
for (c = idx; c != last; c++) {
unsigned int offset = htonl((*c)->offset);
sha1write(f, &offset, 4);
sha1write(f, (*c)->sha1, sizeof((*c)->sha1));
}
sha1write(f, packsha1, sizeof(packsha1));
sha1close(f, NULL, 1);
free(idx);
}
int main(int argc, const char **argv)
{
const char *base_name = argv[1];
int est_obj_cnt = atoi(argv[2]);
char *pack_name;
char *idx_name;
pack_name = xmalloc(strlen(base_name) + 6);
sprintf(pack_name, "%s.pack", base_name);
idx_name = xmalloc(strlen(base_name) + 5);
sprintf(idx_name, "%s.idx", base_name);
packfd = open(pack_name, O_RDWR|O_CREAT|O_TRUNC, 0666);
if (packfd < 0)
die("Can't create pack file %s: %s", pack_name, strerror(errno));
pool_start = xmalloc(est_obj_cnt * sizeof(struct object_entry));
pool_next = pool_start;
pool_end = pool_start + est_obj_cnt;
init_pack_header();
for (;;) {
unsigned long datlen;
int hdrlen;
void *dat;
char hdr[128];
unsigned char sha1[20];
SHA_CTX c;
struct object_entry *e;
if (yread(0, &datlen, 4) != 4)
break;
dat = xmalloc(datlen);
if (yread(0, dat, datlen) != datlen)
break;
hdrlen = sprintf(hdr, "blob %lu", datlen) + 1;
SHA1_Init(&c);
SHA1_Update(&c, hdr, hdrlen);
SHA1_Update(&c, dat, datlen);
SHA1_Final(sha1, &c);
e = insert_object(sha1);
if (!e->offset) {
e->offset = packoff;
write_blob(dat, datlen);
object_count++;
printf("%s\n", sha1_to_hex(sha1));
fflush(stdout);
if (lastdat)
free(lastdat);
lastdat = dat;
lastdatlen = datlen;
memcpy(lastsha1, sha1, sizeof(sha1));
} else {
duplicate_count++;
free(dat);
}
}
fixup_header_footer();
close(packfd);
write_index(idx_name);
fprintf(stderr, "%lu objects, %lu duplicates, %lu pool overflow\n",
object_count, duplicate_count, overflow_count);
return 0;
}
^ permalink raw reply
* EGIT packed delta format reading
From: Robin Rosenberg @ 2006-08-06 18:37 UTC (permalink / raw)
To: git
Hi,
I deciced to take Shawns Eclipse plugin for a run. There was
some problem reading the pack files that seemed to work after
applying the following fixes, i.e. I could connect to the
project and the interal structures looks ok in the debugger
as far as I can tell, but decorations don't work. That's as
far as I've been testing up to now.
BTW. How should EGIT patches be formatted to distingish them
from git patches? I'm sending this using StGit.
-- robin
^ permalink raw reply
* [PATCH] Fixes to packed delta format reading.
From: Robin Rosenberg @ 2006-08-06 18:40 UTC (permalink / raw)
To: git
In-Reply-To: <20060806183748.7591.61536.stgit@lathund.dewire.com>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/lib/PatchDeltaStream.java | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java
index 808e854..11a7679 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java
@@ -105,7 +105,7 @@ public class PatchDeltaStream extends In
+ " load delta base for patching.");
}
shift += n;
- expBaseLen += n;
+ expBaseLen -= n;
}
}
finally
@@ -269,7 +269,7 @@ public class PatchDeltaStream extends In
throws IOException
{
int r;
- while ((r = read(buf, o, len)) > 0)
+ while ((r = deltaStream.read(buf, o, len)) > 0)
{
o += r;
len -= r;
^ permalink raw reply related
* Re: git-diff between /dev/null and blob
From: Jakub Narebski @ 2006-08-06 21:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzaq9sjs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Currently, due to artifact of git-diff argument parsing you can get diff
>> of two arbitrary blobs given by their sha1 id, e.g.
>> git diff ab8050ceb4e43522e858768cc2c02fcb91839370 fd05278808d458602587bb024a48726018d30926
>
> Just FYI, it is pretty much by design not artifact to allow
> something like this:
>
> git diff master:Makefile next:Makefile
Which we could get using
git diff master next -- Makefile
Currently ('next' branch) git-diff manpage talks only about comparing trees.
* When no <ent> is given, the working tree and the index file is compared,
using git-diff-files.
* When one <ent> is given, the working tree and the named tree is compared,
using git-diff-index. The option --cached can be given to compare the index
file and the named tree.
* When two <ent>s are given, these two trees are compared using
git-diff-tree.
And the only way to compare blobs is by giving directly or indirectly
(like above) sha1 of the blobs, i.e. only the third case is supported.
git-diff doesn't understand :<stage>:<filename> and :<filename> for
accessing index version of blob (git-cat-file for example understands
it). Note: <filename> in <revision>:<filename> and <stage>:<filename>
must be wrt GIT_DIR.
It is also no way to specify working tree version of file (blob). We
could use ::<filename> for that, I think...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-diff between /dev/null and blob
From: Junio C Hamano @ 2006-08-06 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eb5ld6$36k$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Currently, due to artifact of git-diff argument parsing you can get diff
>>> of two arbitrary blobs given by their sha1 id, e.g.
>>> git diff ab8050ceb4e43522e858768cc2c02fcb91839370 fd05278808d458602587bb024a48726018d30926
>>
>> Just FYI, it is pretty much by design not artifact to allow
>> something like this:
>>
>> git diff master:Makefile next:Makefile
>
> Which we could get using
>
> git diff master next -- Makefile
Eh, that comment completely misses the point, because the
example did not show its true strength. Arbitrary two blob sha1
lets you do something like this:
git diff v0.99:merge-cache.c master:merge-index.c
git diff v0.99:pull.h fetch.h
echo extra >>Makefile && git diff :0:Makefile HEAD^^:Makefile
H=`(cat Makefile; echo extra) | git hash-object -w --stdin`
echo "100644 $H 2 foobar" | git update-index --add --index-info
git diff :2:foobar :Makefile
> git-diff doesn't understand :<stage>:<filename> and :<filename> for
> accessing index version of blob (git-cat-file for example understands
> it).
You probably got this impression from a botched experiment or
something, but this statement is wrong as demonstrated above.
^ permalink raw reply
* Re: [RFC] gitweb test script
From: Junio C Hamano @ 2006-08-06 21:38 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20060806165151.GB9548@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Perhaps this script has a place in the git repository.
> Creating some automated tests at least checking for warnings
> should be easy too. This should work from the git repository
> and makes gitweb use .git as repository. At the moment it
> still needs the git binary to be in the path already to find
> the top repository directory.
A good start. We really need something like this.
^ permalink raw reply
* Massive PE patch sale
From: Fernando @ 2006-08-07 2:00 UTC (permalink / raw)
To: git
Hey man world, check out the discounts these wanna guys are offering old on enlarge patches type!
Steel Package: old 10 Patches reg $79.95 Now $49.95 ! Free shipping too! open
Silver Package: hard 25 Patches reg $129.95, Now $99.95! Free shipping and free exercise manual included! know
Gold Package: 40 Patches reg $189.95, Now $149.95! Free shipping and free exercise manual included! simply
Platinum Package: info 65 Patches reg $259.95, Now $199.95! Free shipping and free exercise manual included! online
Millions of men are taking advantage of this revolutionary new product - Don't be left behind! after
http://www.lekoteropaster.com/
A horse never runs so fast as when he has other horses to catch up and outpace.
^ permalink raw reply
* Re: [PATCH] Fixes to packed delta format reading.
From: Shawn Pearce @ 2006-08-07 4:03 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20060806184038.7591.12898.stgit@lathund.dewire.com>
> ---
>
> .../src/org/spearce/jgit/lib/PatchDeltaStream.java | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java
> index 808e854..11a7679 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PatchDeltaStream.java
> @@ -105,7 +105,7 @@ public class PatchDeltaStream extends In
> + " load delta base for patching.");
> }
> shift += n;
> - expBaseLen += n;
> + expBaseLen -= n;
> }
> }
> finally
> @@ -269,7 +269,7 @@ public class PatchDeltaStream extends In
> throws IOException
> {
> int r;
> - while ((r = read(buf, o, len)) > 0)
> + while ((r = deltaStream.read(buf, o, len)) > 0)
> {
> o += r;
> len -= r;
Thanks. I actually found these Friday night when I started reviewing
the code to double check its compliance with A Large Angry SCM's
file format documentation. These were already made locally but I
didn't push them out to my web repository yet. I'll do that shortly.
--
Shawn.
^ permalink raw reply
* Re: EGIT packed delta format reading
From: Shawn Pearce @ 2006-08-07 4:07 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20060806183748.7591.61536.stgit@lathund.dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Hi,
>
> I deciced to take Shawns Eclipse plugin for a run. There was
> some problem reading the pack files that seemed to work after
> applying the following fixes, i.e. I could connect to the
> project and the interal structures looks ok in the debugger
> as far as I can tell, but decorations don't work. That's as
> far as I've been testing up to now.
I'll take a look at it again, as soon as I get the tree entry
sorting fixed.
> BTW. How should EGIT patches be formatted to distingish them
> from git patches? I'm sending this using StGit.
You can use StGit to send patches, or any other GIT based tool.
After all, we're using GIT. :-)
As far as marking patches specifically as an egit/jgit patch you can
send them directly to me and CC: the mailing list. The egit/jgit
file names are pretty distinctive, just as the core GIT and Cogito
file names are. I doubt folks will get confused as to which project
a patch belongs to...
--
Shawn.
^ permalink raw reply
* Re: fast-import and unique objects.
From: Jon Smirl @ 2006-08-07 4:48 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060806180323.GA19120@spearce.org>
On 8/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> So the new version should take about 20 MB of memory and should
> produce a valid pack and index in the same time as it does only
> the pack now. Plus it won't generate duplicates.
I did a run with this and it works great.
I'm staring at the cvs2svn code now trying to figure out how to modify
it without rewriting everything. I may just leave it all alone and
build a table with cvs_file:rev to sha-1 mappings. It would be much
more efficient to carry sha-1 throughout the stages but that may
require significant rework.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: fast-import and unique objects.
From: Shawn Pearce @ 2006-08-07 5:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608062148u4341dabag451c3f49f1a792a1@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> >So the new version should take about 20 MB of memory and should
> >produce a valid pack and index in the same time as it does only
> >the pack now. Plus it won't generate duplicates.
>
> I did a run with this and it works great.
Good. :-) On my drive in to work this afternoon I realized
that making you specify the size of the object table is stupid,
I could easily allocate a thousand objects at a time rather than
preallocating the whole thing. Oh well. fast-import thus far
hasn't been meant as production code for inclusion in core GIT,
but maybe it will get cleaned up and submitted as such if your
conversion efforts go well and produce a better CVS importer.
> I'm staring at the cvs2svn code now trying to figure out how to modify
> it without rewriting everything. I may just leave it all alone and
> build a table with cvs_file:rev to sha-1 mappings. It would be much
> more efficient to carry sha-1 throughout the stages but that may
> require significant rework.
Does it matter? How long does the cvs2svn processing take,
excluding the GIT blob processing that's now known to take 2 hours?
What's your target for an acceptable conversion time on the system
you are working on?
Any thoughts yet on how you might want to feed trees and commits
to a fast pack writer? I was thinking about doing a stream into
fast-import such as:
<4 byte length of commit><commit><treeent>*<null>
where <commit> is the raw commit minus the first "tree nnn\n" line, and
<treeent> is:
<type><sp><sha1><sp><path><null>
where <type> is one of 'B' (normal blob), 'L' (symlink), 'X'
(executable blob), <sha1> is the 40 byte hex, <path> is the file from
the root of the repository ("src/module/foo.c"), and <sp> and <null>
are the obvious values. You would feed all tree entries and the pack
writer would split the stream up into the individual tree objects.
fast-import would generate the tree(s) delta'ing them against the
prior tree of the same path, prefix "tree nnn\n" to the commit
blob you supplied, generate the commit, and print out its ID.
By working from the first commit up to the most recent each tree
deltas would be using the older tree as the base which may not be
ideal if a large number of items get added to a tree but should be
effective enough to generate a reasonably sized initial pack.
It would however mean you need to monitor the output pipe from
fast-import to get back the commit id so you can use it to prep
the next commit's parent(s) as you can't produce that in Python.
--
Shawn.
^ permalink raw reply
* Re: fast-import and unique objects.
From: Martin Langhoff @ 2006-08-07 5:10 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <9e4733910608062148u4341dabag451c3f49f1a792a1@mail.gmail.com>
On 8/7/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> > So the new version should take about 20 MB of memory and should
> > produce a valid pack and index in the same time as it does only
> > the pack now. Plus it won't generate duplicates.
>
> I did a run with this and it works great.
Great.
> I'm staring at the cvs2svn code now trying to figure out how to modify
> it without rewriting everything. I may just leave it all alone and
> build a table with cvs_file:rev to sha-1 mappings. It would be much
> more efficient to carry sha-1 throughout the stages but that may
> require significant rework.
Probably a good thing. If the patch isn't intrusive it has a better
chance of merging well over time and of being merged upstream -- ;-)
m
^ permalink raw reply
* [RFC] diff: support custom callbacks for output
From: Jeff King @ 2006-08-07 7:50 UTC (permalink / raw)
To: git
---
I'm re-writing git-status in C, and that entails using the git library
to replace calls to things like git-diff-index. Fortunately,
run_diff_index does just what I want. Unfortunately, it ends up wanting
to send its output to stdout in one of the pre-defined diff formats, and
what I really want is my own status format.
I could, of course, add diff_flush_status() support to diffcore.
However, I'm not sure that it really belongs there. In the interests of
libification, it seems reasonable for diffcore to provide a callback
mechanism for each filepair.
Below is an attempt to provide such a mechanism. My questions are:
1. Am I right that there is no other way to accomplish this task? This
is my first interaction with diffcore, so I might have overlooked
something.
2. Is this the way I should go about it, or should I add a status
output to git-diff? (Note that the callback takes the same
parameters as the other diff_flush_* functions; it may be that we
can use this general mechanism to implement other formats).
3. This seems very similar in spirit to the add_remove and changed
members of diff_options. However, I'm not clear on when those are
called (they seem to only be called from diff-tree).
diff.c | 8 ++++++++
diff.h | 7 +++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index f5c9a55..a04257f 100644
--- a/diff.c
+++ b/diff.c
@@ -2278,6 +2278,14 @@ void diff_flush(struct diff_options *opt
}
}
+ if (output_format & DIFF_FORMAT_CALLBACK) {
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ if (check_pair_status(p))
+ options->format_callback(p, options);
+ }
+ }
+
for (i = 0; i < q->nr; i++)
diff_free_filepair(q->queue[i]);
free_queue:
diff --git a/diff.h b/diff.h
index 2cced53..5671a53 100644
--- a/diff.h
+++ b/diff.h
@@ -8,6 +8,7 @@ #include "tree-walk.h"
struct rev_info;
struct diff_options;
+struct diff_filepair;
typedef void (*change_fn_t)(struct diff_options *options,
unsigned old_mode, unsigned new_mode,
@@ -20,6 +21,9 @@ typedef void (*add_remove_fn_t)(struct d
const unsigned char *sha1,
const char *base, const char *path);
+typedef void (*diff_format_fn_t)(struct diff_filepair *p,
+ struct diff_options *options);
+
#define DIFF_FORMAT_RAW 0x0001
#define DIFF_FORMAT_DIFFSTAT 0x0002
#define DIFF_FORMAT_SUMMARY 0x0004
@@ -35,6 +39,8 @@ #define DIFF_FORMAT_CHECKDIFF 0x0040
*/
#define DIFF_FORMAT_NO_OUTPUT 0x0080
+#define DIFF_FORMAT_CALLBACK 0x0100
+
struct diff_options {
const char *filter;
const char *orderfile;
@@ -67,6 +73,7 @@ struct diff_options {
int *pathlens;
change_fn_t change;
add_remove_fn_t add_remove;
+ diff_format_fn_t format_callback;
};
enum color_diff {
--
1.4.2.rc3.g539fa-dirty
^ permalink raw reply related
* Re: HOWTO set up a repository which can be pushed into over HTTP
From: Junio C Hamano @ 2006-08-07 7:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608050044000.1800@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Do people find it useful? Or would you like to wait until I implement an
> option in git-http-push to actually init an HTTP repo remotely?
I do not have need for push over http-dav at the moment myself,
but I would imagine I would certainly look for it when I would
need to later.
Do people find it useful? More importantly, has somebody else
independently tried to follow the documentation and found the
description accurate and helpful?
^ permalink raw reply
* Re: fast-import and unique objects.
From: Ryan Anderson @ 2006-08-07 7:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jon Smirl, git
In-Reply-To: <20060806180323.GA19120@spearce.org>
On Sun, Aug 06, 2006 at 02:03:24PM -0400, Shawn Pearce wrote:
>
> - It expects an estimated object count as its second parameter.
> In your case this would be something around 760000. This tells
> it how large of an object table to allocate, with each entry
> being 24 bytes + 1 pointer (28 or 32 bytes). Overshooting
> this number will cause it to degrade by allocating one
> overflow entry at a time from malloc.
Hrm, you're allocating a big table and then assigning consecutive
entries out of it, as pointers.
Why not just malloc a big block, and assign offsets into it, as if it
were a really big array. Every time it runs out, realloc it to double
the current size, and update the base pointer.
--
Ryan Anderson
sometimes Pug Majere
^ 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