* [PATCH] gitweb: Fix git_blame
From: Aneesh Kumar K.V @ 2006-09-01 3:43 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitweb-Fix-git_blame.txt --]
[-- Type: text/plain, Size: 1806 bytes --]
Converting the default values to array broke the git blame enable
disable support. Fix the same.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
gitweb/gitweb.perl | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0984e85..57ffa25 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2251,7 +2251,8 @@ sub git_blame2 {
my $fd;
my $ftype;
- if (!gitweb_check_feature('blame')) {
+ my ($have_blame) = gitweb_check_feature('blame');
+ if (!$have_blame) {
die_error('403 Permission denied', "Permission denied");
}
die_error('404 Not Found', "File name not defined") if (!$file_name);
@@ -2320,7 +2321,8 @@ HTML
sub git_blame {
my $fd;
- if (!gitweb_check_feature('blame')) {
+ my ($have_blame) = gitweb_check_feature('blame');
+ if (!$have_blame) {
die_error('403 Permission denied', "Permission denied");
}
die_error('404 Not Found', "File name not defined") if (!$file_name);
@@ -2494,7 +2496,7 @@ sub git_blob {
die_error(undef, "No file name defined");
}
}
- my $have_blame = gitweb_check_feature('blame');
+ my ($have_blame) = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -2570,7 +2572,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $base = "";
- my $have_blame = gitweb_check_feature('blame');
+ my ($have_blame) = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
git_print_page_nav('tree','', $hash_base);
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
--
1.4.2.rc1.g83e1-dirty
^ permalink raw reply related
* Re: problem with git-cvsserver
From: Marco Roeland @ 2006-09-01 7:05 UTC (permalink / raw)
To: Martin Langhoff
Cc: Marco Roeland, Junio C Hamano, aonghus, git, Johannes Schindelin
In-Reply-To: <46a038f90608311707t4ab5fc2fj45e852df4b91870f@mail.gmail.com>
On Friday September 1st 2006 at 12:07 Martin Langhoff wrote:
[warning: discussion about sqlite; no direct git serviceable parts inside!]
> >I have to say though: Ouch. Do you know if there's an upgrade path for
> >apps? Does v3 detect you've got a v2 file and do something smart
> >(upgrade in place / spit out a readable error)?
Applications for both v2 and v3 can work on the same machine at the same
time. Both versions will not corrupt a database of the other version
and will immediately stop with an error, although the error isn't very
readable (doesn't mention _which_ version it saw or needed).
They do not perform an upgrade in place.
But as sqlite or sqlite3 databases are standalone files, most of the
time just use the sqlite version that is standard for your platform
and/or version. For new development v3 is the way to go, as v2 is in
deep sleep maintenance now.
Not just the database format changed in v3, the whole API changed
incompatibly.
> Oh, grumble. See the comment at the bottom of
> http://www.sqlite.org/formatchng.html
>
> We may need to add something in the doco pointing to this "technique",
> and perhaps the URL as later versions may do something different.
>
> I do wonder what the debian packaging does, perhaps the v3 package
> forces an upgrade to the v2 package that renames the cli binary? I
> guess the drawback of having the DBs anywhere in the FS is that the
> packaging can't upgrade them for you as it does with Pg for instance
> :(
The commandline programs are called 'sqlite' and 'sqlite3' so there is
no "upgrade", you can have the two different versions simultaneously
installed and working on the same machine.
Unfortunately the 'sqlite3' doesn't directly read the 'sqlite' format
and neither the other way round. You can convert a database easily from
the one format to the other:
$ echo .dump | sqlite database.v2.dat > dump.v2.dat
$ sqlite3 < dump.v2.dat database.v3.dat
If you don't use the new features in sqlite3 you can even convert back
in the same way:
$ echo .dump | sqlite3 database.v3.dat > dump.v3.dat
$ sqlite < dump.v3.dat database.v2.dat
Use a non-existent file for the target database, and sqlite(3) will
create the database for you. Do check the conversion as error reporting
in the commandline tools in this "batch" mode is sometimes rather sparse
or non-existent!
Once you got it finally going I find that sqlite(3) is a fast, reliable
and quite handy database. Especially, as Johannes said, its standalone
nature makes developing and deploying very easy.
--
Marco Roeland
^ permalink raw reply
* Re: Mozilla .git tree
From: Junio C Hamano @ 2006-09-01 7:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds
In-Reply-To: <7vzmdmh2lu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Nicolas Pitre <nico@cam.org> writes:
>
>> And the zlib header contains a CRC which we're about to use for
>> validating the data when doing delta data reuse in order to prevent pack
>> corruption propagation like the one recently posted on the list.
>
> Ah, never thought of using the CRC directly. I was thinking
> about inflating into void and see if it succeeds, which as you
> say is perhaps quite expensive.
>
> This brings me back to my pet-peeve, though. I do not think
> zlib stream seeks back and leaves some clue at the beginning to
> tell me the deflated length, so it is quite hard to find where
> each deflated stream ends in a packfile cheaply. Loose objects
> (with new or legacy style header) are easy (st.st_size is
> available), but I do not think of a way short of building a
> reverse index of pack .idx file, which means I am already
> talking about not so cheap way X-<.
>
> It might be a reason to define a new .idx format. We could lift
> 32-bit offset limitation while we are at it. Each entry could
> have 20-byte hash, 64-bit offset into the corresponding .pack,
> and 32-bit deflated length (heh, why not make it 64-bit while we
> are at it). Luckily, .idx _is_ a local matter so we can even
> have a flag day and tell people to run the updated index-pack on
> existing packfiles to regenerate .idx.
So I whipped up this as the zeroth step to propose a migration
plan:
Step 0. Prepare conversion and debugging tool.
Step 1. Prepare sha1_file (consumer) side to understand the
idx file in the new format. I haven't decided if
making the runtime to understand both formats is
feasible; I believe it is with what we currently do,
but finding out where the end of each pack entry
cheaply was one of the side effects I wanted to get
from this conversion whose primary purpose is to bust
the 4GB ceiling
Step 2. Update pack-objects and index-pack to emit the new
format.
Step 3. Work on integrating partial mmap() support with Shawn.
This is more or less orthogonal to 4GB ceiling (people
would hit mmap() limit even with a 1.5GB pack), but I
suspect it would be necessary to be able to tell where
the end of each pack entry is cheaply to implement
this.
This patch is step 0.
-- >8 --
Subject: [PATCH] convert-idx: prepare large pack idx support.
This adds git-convert-idx which converts between the traditional
32-bit offset pack .idx file and the new 64-bit offset pack .idx
file, and updates git-show-index to understand both formats.
Don't get too excited, not just yet. The programs pack-objects
and index-pack need to be updated to produce 64-bit pack .idx
files, and the core sha1_file routines also needs to be told
about the new format.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 1
builtin-convert-idx.c | 351 +++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1
git.c | 1
show-index.c | 36 ++++-
5 files changed, 384 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 05bd77f..fccf747 100644
--- a/Makefile
+++ b/Makefile
@@ -260,6 +260,7 @@ BUILTIN_OBJS = \
builtin-check-ref-format.o \
builtin-commit-tree.o \
builtin-count-objects.o \
+ builtin-convert-idx.o \
builtin-diff.o \
builtin-diff-files.o \
builtin-diff-index.o \
diff --git a/builtin-convert-idx.c b/builtin-convert-idx.c
new file mode 100644
index 0000000..af111d2
--- /dev/null
+++ b/builtin-convert-idx.c
@@ -0,0 +1,351 @@
+#include "cache.h"
+
+/*****************************************************************
+
+The differences between the original and new style pack-*.idx files
+are as follows:
+
+ - A new style .idx file can record 64-bit offsets into corresponding
+ .pack file (an original .idx has 32-bit offsets hence limiting the
+ .pack file to 4GB).
+
+ - A new style .idx file allows finding out the end of one entry in
+ the .pack (you need to find the object with next offset in an
+ original .idx file).
+
+Other than these major differences, the overall structure is quite
+similar.
+
+A new style .idx file begins with a signature, "\377tOc", and a
+version number as a 4-byte network byte order integer. The version
+of this implementation is 2.
+
+The location of the signature used to hold the number of objects in
+the pack whose object name start with byte 0x00 as a 4-byte integer in
+the network byte order. The original .idx format allowed only 32-bit
+offset into the pack, and data for 0xFF744F63 objects would certainly
+exceed 4GB (because an object needs at least 1-byte for type and its
+deflated length, and deflated data will be 1 or more bytes), so the
+older git would not mistake the new style .idx file as something
+valid.
+
+Following the signature and the version number is a header, which
+consists of 256 4-byte network byte order integers. N-th entry of
+this table records the number of objects in the corresponding pack,
+the first byte of whose object name are smaller than N. This means a
+.pack file is still limited to maximum 4 billion objects.
+
+The header is followed by the main toc table, which is a list of
+N-byte entries, one entry per object in the pack, sorted by the object
+name. Each entry is:
+
+ . 8-byte network byte order integer, recording where the object is
+ stored in the packfile as the offset from the beginning.
+
+ . 4-byte network byte order integer, recording the location of the
+ next object in the main toc table.
+
+ . 20-byte object name.
+
+The file is concluded with a trailer:
+
+ . A copy of the 20-byte SHA-1 checksum at the end of the
+ corresponding packfile.
+
+ . 20-byte SHA-1 checksum of all of the above.
+
+******************************************************************/
+
+#define PACK_IDX_SIGNATURE 0xFF744F63 /* "\377tOc" */
+#define PACK_IDX_VERSION 2
+
+static unsigned get4(const void *buf, unsigned long offset)
+{
+ const unsigned char *p = ((const unsigned char *)buf) + offset;
+
+ return (p[3] | (p[2]<<8) | (p[1]<<16) | (p[0]<<24));
+}
+
+static unsigned long long get8(const void *buf, unsigned long offset)
+{
+ unsigned long long n, m;
+ n = get4(buf, offset);
+ m = get4(buf, offset + 4);
+ return (n << 32) | m;
+}
+
+static void put4(void *buf, unsigned long offset, unsigned data)
+{
+ unsigned char *p = ((unsigned char *)buf) + offset;
+
+ p[3] = data; data >>= 8;
+ p[2] = data; data >>= 8;
+ p[1] = data; data >>= 8;
+ p[0] = data;
+}
+
+static void put8(void *buf, unsigned long offset, unsigned long long data)
+{
+ put4(buf, offset, data >> 32);
+ put4(buf, offset + 4, data);
+}
+
+static int write_out(const char *path, void *data, unsigned long sz)
+{
+ char newpath[PATH_MAX];
+ int fd;
+
+ if (PATH_MAX < strlen(path) + 10)
+ return error("%s: pathname too long", path);
+ sprintf(newpath, "%s_XXXXXX", path);
+ fd = mkstemp(newpath);
+ if (fd < 0)
+ return error("%s: unable to create temporary file: %s",
+ newpath, strerror(errno));
+ write_or_die(fd, data, sz);
+ return rename(newpath, path);
+}
+
+static int downgrade_idx(const char *path, const unsigned char *data, unsigned long sz)
+{
+ unsigned i, num = 0;
+ unsigned osz;
+ unsigned char *odata, *otable;
+ const unsigned char *table;
+ unsigned char hash[20];
+ SHA_CTX ctx;
+
+ if (get4(data, 0) != PACK_IDX_SIGNATURE)
+ return error("%s is not a new style index", path);
+ if (get4(data, 4) != 2)
+ return error("%s: version %u of new style index not supported",
+ path, get4(data, 4));
+
+ /* Validate the fan-out and find out the number of objects */
+ for (i = 0; i < 256; i++) {
+ unsigned n = get4(data + 8, i * 4);
+ if (n < num)
+ return error("%s: corrupt old index file", path);
+ num = n;
+ }
+
+ /* Make sure the sz is correct */
+ if (sz != 8 + 4 * 256 + 32 * num + 40)
+ return error("%s: new index file with incorrect size", path);
+
+ /* Make sure the hash matches */
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, data, sz - 20);
+ SHA1_Final(hash, &ctx);
+ if (memcmp(hash, data + sz - 20, 20))
+ return error("%s: new index file with incorrect hash", path);
+
+ osz = 4 * 256 + 24 * num + 40;
+ odata = xcalloc(1, osz);
+
+ /* Convert the fan-out */
+ for (i = 0; i < 256; i++)
+ put4(odata, i * 4, get4(data + 8, i * 4));
+
+ /* Make them point at the main table */
+ table = data + 4 * 256 + 8;
+ otable = odata + 4 * 256;
+
+ /* Convert entries, while validating that they are sorted */
+ for (i = 0; i < num; i++) {
+ unsigned long long ofs = get8(table, 32 * i);
+ unsigned const char *hash1, *hash2;
+
+ if (ofs & (0xFFFFFFFFLL << 32))
+ return error("%s: the packfile is too big to be "
+ "indexed with an old index", path);
+ put4(otable + 24 * i, 0, ofs);
+ memcpy(otable + 24 * i + 4, table + 32 * i + 12, 20);
+ if (!i)
+ continue;
+ hash1 = table + 32 * (i-1) + 12;
+ hash2 = hash1 + 32;
+ if (0 <= memcmp(hash1, hash2, 20))
+ return error("%s: new index file with unsorted table",
+ path);
+ if (*hash1 != *hash2) {
+ /* fan-out of hash1[0] should point here */
+ if (get4(data + 8, *hash1 * 4) != i)
+ return error("%s: old index file with "
+ "invalid fan-out", path);
+ }
+ }
+
+ /* Copy the pack SHA-1 checksum */
+ memcpy(odata + osz - 40, data + sz - 40, 20);
+
+ /* Compute the overall SHA-1 checksum */
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, odata, osz - 20);
+ SHA1_Final(odata + osz - 20, &ctx);
+
+ /* Write it out */
+ return write_out(path, odata, osz);
+}
+
+static int map_compare(const void *a_, const void *b_)
+{
+ /* These point at new style table entry whose first element is
+ * 8-byte network byte order offset. Compare them
+ */
+ const char *a = *((const char **)a_);
+ const char *b = *((const char **)b_);
+ unsigned long long aofs, bofs;
+
+ aofs = get8(a, 0);
+ bofs = get8(b, 0);
+ if (aofs < bofs)
+ return -1;
+ if (aofs == bofs)
+ return 0;
+ return 1;
+}
+
+static int upgrade_idx(const char *path, const unsigned char *data, unsigned long sz)
+{
+ const unsigned char *table;
+ unsigned char *ndata, *ntable, **map;
+ unsigned i, num = 0;
+ unsigned nsz;
+ unsigned prev_ix;
+ unsigned char hash[20];
+ SHA_CTX ctx;
+
+ if (get4(data, 0) == PACK_IDX_SIGNATURE)
+ return error("%s is a new style index", path);
+
+ /* Validate the fan-out and find out the number of objects */
+ for (i = 0; i < 256; i++) {
+ unsigned n = get4(data, i * 4);
+ if (n < num)
+ return error("%s: corrupt old index file", path);
+ num = n;
+ }
+
+ /* Make sure the sz is correct */
+ if (sz != 4 * 256 + 24 * num + 40)
+ return error("%s: old index file with incorrect size", path);
+
+ /* Make sure the hash matches */
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, data, sz - 20);
+ SHA1_Final(hash, &ctx);
+ if (memcmp(hash, data + sz - 20, 20))
+ return error("%s: old index file with incorrect hash", path);
+
+ nsz = 8 + 4 * 256 + 32 * num + 40;
+ ndata = xcalloc(1, nsz);
+ map = xcalloc(sizeof(*map), num);
+
+ put4(ndata, 0, PACK_IDX_SIGNATURE);
+ put4(ndata, 4, PACK_IDX_VERSION);
+
+ /* Convert the fan-out */
+ for (i = 0; i < 256; i++)
+ put4(ndata, 8 + i * 4, get4(data, i * 4));
+
+ /* Make them point at the main table */
+ table = data + 4 * 256;
+ ntable = ndata + 8 + 4 * 256;
+
+ /* Convert entries, while validating that they are sorted */
+ for (i = 0; i < num; i++) {
+ unsigned ofs = get4(table, 24 * i);
+ unsigned const char *hash1, *hash2;
+ map[i] = ntable + 32 * i;
+ put8(ntable + 32 * i, 0, ofs);
+ memcpy(ntable + 32 * i + 12, table + 24 * i + 4, 20);
+ if (!i)
+ continue;
+ hash1 = table + 24 * (i-1) + 4;
+ hash2 = hash1 + 24;
+ if (0 <= memcmp(hash1, hash2, 20))
+ return error("%s: old index file with unsorted table",
+ path);
+ if (*hash1 != *hash2) {
+ /* fan-out of hash1[0] should point here */
+ if (get4(data, *hash1 * 4) != i)
+ return error("%s: old index file with "
+ "invalid fan-out", path);
+ }
+ }
+
+ /* Using the reverse map, fill in the next object number */
+ qsort(map, num, sizeof(*map), map_compare);
+ prev_ix = (map[0] - ntable) / 32;
+ for (i = 1; i < num; i++) {
+ /* map is an array of main table entry index,
+ * sorted by the offset of the pack data.
+ */
+ unsigned next_ix = (map[i] - ntable) / 32;
+ put4(ntable + 32 * prev_ix, 8, next_ix);
+ prev_ix = next_ix;
+ }
+ put4(map[num-1], 8, num); /* Mark the last entry with num */
+
+ /* Copy the pack SHA-1 checksum */
+ memcpy(ndata + nsz - 40, data + sz - 40, 20);
+
+ /* Compute the overall SHA-1 checksum */
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, ndata, nsz - 20);
+ SHA1_Final(ndata + nsz - 20, &ctx);
+
+ /* Write it out */
+ return write_out(path, ndata, nsz);
+}
+
+static int convert_one(const char *path, int downgrade)
+{
+ int fd, err;
+ struct stat st;
+ void *map;
+
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return error("%s: cannot open: %s", path, strerror(errno));
+ if (fstat(fd, &st)) {
+ err = errno;
+ close(fd);
+ return error("%s: cannot stat: %s", path, strerror(err));
+ }
+ map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ close(fd);
+ err = downgrade
+ ? downgrade_idx(path, map, st.st_size)
+ : upgrade_idx(path, map, st.st_size);
+ munmap(map, st.st_size);
+ return err;
+}
+
+static const char convert_idx_usage[] =
+"git-convert-idx [-d] <file>";
+
+int cmd_convert_idx(int ac, const char **av, const char *prefix)
+{
+ int i, downgrade = 0, status = 0;
+
+ for (i = 1; i < ac; i++) {
+ const char *arg = av[i];
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-d") || !strcmp(arg, "--downgrade")) {
+ downgrade = 1;
+ continue;
+ }
+ usage(convert_idx_usage);
+ }
+
+ for ( ; i < ac; i++)
+ status |= convert_one(av[i], downgrade);
+ return status;
+}
diff --git a/builtin.h b/builtin.h
index 25431d7..e282cb8 100644
--- a/builtin.h
+++ b/builtin.h
@@ -19,6 +19,7 @@ extern int cmd_cat_file(int argc, const
extern int cmd_checkout_index(int argc, const char **argv, const char *prefix);
extern int cmd_check_ref_format(int argc, const char **argv, const char *prefix);
extern int cmd_commit_tree(int argc, const char **argv, const char *prefix);
+extern int cmd_convert_idx(int ac, const char **av, const char *prefix);
extern int cmd_count_objects(int argc, const char **argv, const char *prefix);
extern int cmd_diff_files(int argc, const char **argv, const char *prefix);
extern int cmd_diff_index(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 05871ad..22dbad8 100644
--- a/git.c
+++ b/git.c
@@ -230,6 +230,7 @@ static void handle_internal_command(int
{ "checkout-index", cmd_checkout_index, RUN_SETUP },
{ "check-ref-format", cmd_check_ref_format },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
+ { "convert-idx", cmd_convert_idx },
{ "count-objects", cmd_count_objects },
{ "diff", cmd_diff, RUN_SETUP },
{ "diff-files", cmd_diff_files, RUN_SETUP },
diff --git a/show-index.c b/show-index.c
index c21d660..a00b691 100644
--- a/show-index.c
+++ b/show-index.c
@@ -1,14 +1,28 @@
#include "cache.h"
+#define PACK_IDX_SIGNATURE 0xFF744F63 /* "\377tOc" */
+#define PACK_IDX_VERSION 2
+
int main(int argc, char **argv)
{
int i;
unsigned nr;
- unsigned int entry[6];
+ unsigned int entry[8];
static unsigned int top_index[256];
+ int new_style = 0;
if (fread(top_index, sizeof(top_index), 1, stdin) != 1)
- die("unable to read idex");
+ die("unable to read index");
+
+ if (ntohl(top_index[0]) == PACK_IDX_SIGNATURE) {
+ fprintf(stderr, "new style idx version %u\n",
+ ntohl(top_index[1]));
+ memmove(top_index, top_index + 2, 4 * 254);
+ if (fread(top_index + 254, sizeof(unsigned), 2, stdin) != 2)
+ die("unable to read index");
+ new_style = 1;
+ }
+
nr = 0;
for (i = 0; i < 256; i++) {
unsigned n = ntohl(top_index[i]);
@@ -16,13 +30,23 @@ int main(int argc, char **argv)
die("corrupt index file");
nr = n;
}
+
for (i = 0; i < nr; i++) {
- unsigned offset;
+ unsigned long long offset;
- if (fread(entry, 24, 1, stdin) != 1)
+ if (fread(entry,
+ new_style ? 32 : 24,
+ 1, stdin) != 1)
die("unable to read entry %u/%u", i, nr);
- offset = ntohl(entry[0]);
- printf("%u %s\n", offset, sha1_to_hex((void *)(entry+1)));
+ if (new_style) {
+ offset = ntohl(entry[0]);
+ offset = (offset << 32) | ntohl(entry[1]);
+ }
+ else {
+ offset = ntohl(entry[0]);
+ }
+ printf("%llu %s\n", offset,
+ sha1_to_hex((void *)(entry + 1 + new_style * 2)));
}
return 0;
}
--
1.4.2.gc9dce
^ permalink raw reply related
* [PATCH] fmt-merge-msg: fix off-by-one bug
From: Johannes Schindelin @ 2006-09-01 8:49 UTC (permalink / raw)
To: git, junkio
Thanks to the recent malloc()->xmalloc() change, and XMALLOC_POISON, this bug
was found.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-fmt-merge-msg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index ed59e77..432963d 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -142,7 +142,7 @@ static int handle_line(char *line)
if (origin[0] == '\'' && origin[len - 1] == '\'') {
char *new_origin = xmalloc(len - 1);
memcpy(new_origin, origin + 1, len - 2);
- new_origin[len - 1] = 0;
+ new_origin[len - 2] = 0;
origin = new_origin;
} else
origin = strdup(origin);
--
1.4.2.gc2fc-dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: Fix git_blame
From: Jakub Narebski @ 2006-09-01 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <ed8a90$pfn$1@sea.gmane.org>
Aneesh Kumar wrote:
> Converting the default values to array broke the git blame enable
> disable support. Fix the same.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Hmmm.... git^W got applied (1d3fc68a), but commit message was lost.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Joining a fixed archive with its continuation
From: Sergio Callegari @ 2006-09-01 11:56 UTC (permalink / raw)
To: git
Hi,
I am trying to follow Johannes (Dscho) suggestions to join a fixed
archive with a new archive, that is its continuation from the latest
working tree.
I am having some trouble with rebase, and any help would be appreciated.
>
> You can "graft" the new onto the old branch:
>
Yes, grafts are fine... however, if I am to use push/pull for
transferring data between two computers I am working on, I'd like better
a "history rewriting" approach, so that I do not need to manually copy
the grafts.
> NOTE! This is the quickest way if you want to have the history _locally_.
>
> If you want to be able to distribute it (or synchronize it between your
> laptop and PC _with git!_), you can rewrite the history by either
> git-rebase, or by using cg-admin-rewritehist if you are using cogito.
>
>
I have tried using git-rebase (I do not have cg, at least not yet).
However I am encountering some problems...
Everything is fine with the master branch of my continuation archive doing
git rebase fixed-master master
(where fixed-master is the master head of the recovered archive)
This does the trick nicely. I.e. I start with
A---B---C---D E---F---G---H---I
where D is fixed-master and I is master, and I end up with
A---B---C---D---E'---F'---G'---H'---I'
plus the older tree E---...---I
However I am then in trouble with the other branches of the continuation
archive, which I simply cannot get right...
In fact, E...I has actually a branch, say at G, like in
E---F---G---H---I
\
--M---N
And I cannot make an M'---N' based at G'... the best that I am
succeeding in is building an
E''--F''--G''--M'--N'
based on D.
> Ciao,
> Dscho
>
> P.S.: Of course, if you do not insist on a super clean history, you can
> fake a merge. Just put <40-hex-chars-old> into .git/MERGE_HEAD and commit.
> This will pretend that your new head and your old head were merged, and
> the result is the new head. This _should_ even work with git-bisect, but
> it is slightly ugly.
Before I try, can you better explain me what shall go on in this case?
The man page of commit actually does not say much about commit behavior
during a merge (i.e. with MERGE_HEAD set).
Thanks,
Sergio
^ permalink raw reply
* Re: Compiling git-snapshot-20069831
From: Jorma Karvonen @ 2006-09-01 13:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608311904520.28360@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 31 Aug 2006, Jorma Karvonen wrote:
>
>
>> I tried
>>
>> make configure
>>
>> and got an error message:
>>
>> /bin/sh: curl-config: command not found
>> make: **** No rule to make target `configure'. Stop.
>>
>
> Okay. I deem this a bug in our Makefile.
>
> Could you please try "autoconf" and _then_ "./configure"?
>
> Hth,
> Dscho
>
>
Hi,
I tried git-snapshot-20060901 and everything is now OK.
make prefix=/usr/local NEEDS_LIBICONV=1 NO_CURL=1
and
make prefix=/usr/local NEEDS_LIBICONV=1 NO_CURL=1 install
were the correct commands and git is now installed.
Thank you very much,
Jorma Karvonen
^ permalink raw reply
* Re: Joining a fixed archive with its continuation
From: Jakub Narebski @ 2006-09-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <44F81FE5.1040509@arces.unibo.it>
Sergio Callegari wrote:
>> If you want to be able to distribute it (or synchronize it between your
>> laptop and PC _with git!_), you can rewrite the history by either
>> git-rebase, or by using cg-admin-rewritehist if you are using cogito.
>>
>>
> I have tried using git-rebase (I do not have cg, at least not yet).
> However I am encountering some problems...
>
> Everything is fine with the master branch of my continuation archive doing
>
> git rebase fixed-master master
>
> (where fixed-master is the master head of the recovered archive)
> This does the trick nicely. I.e. I start with
>
> A---B---C---D E---F---G---H---I
>
>
> where D is fixed-master and I is master, and I end up with
>
> A---B---C---D---E'---F'---G'---H'---I'
>
> plus the older tree E---...---I
>
> However I am then in trouble with the other branches of the continuation
> archive, which I simply cannot get right...
> In fact, E...I has actually a branch, say at G, like in
>
> E---F---G---H---I
> \
> --M---N
>
>
> And I cannot make an M'---N' based at G'... the best that I am
> succeeding in is building an
>
> E''--F''--G''--M'--N'
>
> based on D.
It is where --onto parameter of git-rebase is used. It means you use
<upstream> parameter to identify main branch in the continuation archive,
<branch> parameter being the branch you want to transplant into main
archive (i.e. <upstream>..<branch> being the part you want to
transplant/rebase), and '--onto <newbase>' with <newbase> being the new
fork point.
So in the abovementioned case, try
git rebase --onto G' I N
and tell us if it works.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Joining a fixed archive with its continuation
From: Johannes Schindelin @ 2006-09-01 14:37 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <44F81FE5.1040509@arces.unibo.it>
Hi,
On Fri, 1 Sep 2006, Sergio Callegari wrote:
> > P.S.: Of course, if you do not insist on a super clean history, you can fake
> > a merge. Just put <40-hex-chars-old> into .git/MERGE_HEAD and commit. This
> > will pretend that your new head and your old head were merged, and the
> > result is the new head. This _should_ even work with git-bisect, but it is
> > slightly ugly.
>
> Before I try, can you better explain me what shall go on in this case?
> The man page of commit actually does not say much about commit behavior
> during a merge (i.e. with MERGE_HEAD set).
A merge commit is almost the same as a regulaar commit; the only
difference is that you provide multiple parents to a merge commit. The
first parent is always the current head. And the other parents are in
.git/MERGE_HEAD (one commit SHA1 per line).
So, putting the fixed-master SHA1 into .git/MERGE_HEAD pretends that the
fixed-master merged with the current master is the current master.
>From a view point of correctness, this is _wrong_. _But_ it would work
correctly with pull/push/bisect.
Ciao,
Dscho
^ permalink raw reply
* Re: Mozilla .git tree
From: A Large Angry SCM @ 2006-09-01 17:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7vzmdmh2lu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
>> And the zlib header contains a CRC which we're about to use for
>> validating the data when doing delta data reuse in order to prevent pack
>> corruption propagation like the one recently posted on the list.
>
> Ah, never thought of using the CRC directly. I was thinking
> about inflating into void and see if it succeeds, which as you
> say is perhaps quite expensive.
Unfortunately, the zlib CRC is of the _uncompressed_ data [1], so
inflating the stream is still necessary to check for corruption.
[1] RFC 1950, "ZLIB Compressed Data Format Specification", May 1996.
Pages 4-6.
^ permalink raw reply
* Re: Mozilla .git tree
From: Linus Torvalds @ 2006-09-01 18:35 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <44F871BA.3070303@gmail.com>
On Fri, 1 Sep 2006, A Large Angry SCM wrote:
>
> Unfortunately, the zlib CRC is of the _uncompressed_ data [1], so
> inflating the stream is still necessary to check for corruption.
I don't think that is unfortunate.
We really should inflate the stream anyway, since not only inflating it,
but also applying any deltas to the base object is really the only way to
verify its correctness for a delta thing. Otherwise, the SHA1 of the base
could be totally corrupt.
And once you inflate it and apply all deltas, you obviously also get the
full SHA1 check, so you're _really_ safe.
So let's do the really safe thing first, and see if it actually results in
any problems.
NOTE NOTE NOTE! We might well choose to do this checking _only_ when we
write the index file (ie we have "!pack_to_stdout" set). Why? Because if
we pack to stdout, and don't generate an index file, then by _definition_
the other end has to do the index generation, which means that the other
end will be doing all the SHA1 re-calculation and sanity checking (and
thus inflation and CRC checking).
So this means that if we only do this for the "!pack_to_stdout" case, we
won't be adding any overhead to the git network protocol server, only to
"git repack". Which is exactly what we want to do.
Linus
^ permalink raw reply
* [PATCH] Documentation: Fix howto/revert-branch-rebase.html generation
From: Sergey Vlasov @ 2006-09-01 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT mailing list, Sergey Vlasov
The rule for howto/*.html used "$?", which expands to the list of all
newer prerequisites, including asciidoc.conf added by another rule.
"$<" should be used instead.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
Documentation/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index ed8b886..c00f5f6 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -107,7 +107,7 @@ WEBDOC_DEST = /pub/software/scm/git/docs
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
rm -f $@+ $@
- sed -e '1,/^$$/d' $? | asciidoc -b xhtml11 - >$@+
+ sed -e '1,/^$$/d' $< | asciidoc -b xhtml11 - >$@+
mv $@+ $@
install-webdoc : html
--
1.4.2.g914b
^ permalink raw reply related
* [PATCH] gitweb: gitweb_check_feature always return list
From: Jakub Narebski @ 2006-09-01 19:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <ed8a90$pfn$1@sea.gmane.org>
Modified feature_blame so it returns one-element list and not scalar,
thus making gitweb_check_feature always return list. Updated comment
to explain that part.
This is continuation of Aneesh Kumar work:
gitweb: Fix git_blame
"Converting the default values to array broke the git blame enable
disable support. Fix the same."
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
We could modify %feature hash so the 'default' value could be either
array reference or a scalar instead.
gitweb/gitweb.perl | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 57ffa25..06bdb0e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -74,9 +74,12 @@ our %feature = (
#
# if feature is overridable (it means that allow-override has true value,
# then feature-sub will be called with default options as parameters;
- # return value of feature-sub indicates if to enable specified feature
+ # return value of feature-sub indicates if to enable specified feature,
+ # and is taken to be current parameters of the feature
#
- # use gitweb_check_feature(<feature>) to check if <feature> is enabled
+ # use gitweb_check_feature(<feature>) to check if <feature> is enabled;
+ # to be more exact to get current parameters of <feature>;
+ # gitweb_check_feature(<feature>) returns array (list) of current options
'blame' => {
'sub' => \&feature_blame,
@@ -111,12 +114,12 @@ sub feature_blame {
my ($val) = git_get_project_config('blame', '--bool');
if ($val eq 'true') {
- return 1;
+ return (1);
} elsif ($val eq 'false') {
- return 0;
+ return (0);
}
- return $_[0];
+ return ($_[0]);
}
# To disable system wide have in $GITWEB_CONFIG
--
1.4.1.1
^ permalink raw reply related
* Re: [PATCH] gitweb: gitweb_check_feature always return list
From: Junio C Hamano @ 2006-09-01 19:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11571390683018-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Modified feature_blame so it returns one-element list and not scalar,
> thus making gitweb_check_feature always return list. Updated comment
> to explain that part.
I do not understand what you are fixing.
sub A { return (1); }
sub B { return 1; }
Don't they quack the same way?
^ permalink raw reply
* Re: [PATCH] gitweb: gitweb_check_feature always return list
From: Jakub Narebski @ 2006-09-01 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vk64n5qep.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Modified feature_blame so it returns one-element list and not scalar,
>> thus making gitweb_check_feature always return list. Updated comment
>> to explain that part.
>
> I do not understand what you are fixing.
>
> sub A { return (1); }
> sub B { return 1; }
>
> Don't they quack the same way?
Well, that is just nitpicking. gitweb_check_feature returns list if feature
is not overridable, so I made it that it always returns list.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Mozilla .git tree
From: Junio C Hamano @ 2006-09-01 19:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609011129270.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 1 Sep 2006, A Large Angry SCM wrote:
>>
>> Unfortunately, the zlib CRC is of the _uncompressed_ data [1], so
>> inflating the stream is still necessary to check for corruption.
>
> I don't think that is unfortunate.
>
> We really should inflate the stream anyway, since not only inflating it,
> but also applying any deltas to the base object is really the only way to
> verify its correctness for a delta thing. Otherwise, the SHA1 of the base
> could be totally corrupt.
>
> And once you inflate it and apply all deltas, you obviously also get the
> full SHA1 check, so you're _really_ safe.
>
> So let's do the really safe thing first, and see if it actually results in
> any problems.
I think this makes sense.
^ permalink raw reply
* Re: [PATCH] gitweb: gitweb_check_feature always return list
From: Jakub Narebski @ 2006-09-01 20:12 UTC (permalink / raw)
To: git
In-Reply-To: <eda2q0$la8$1@sea.gmane.org>
<opublikowany i wysłany>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Modified feature_blame so it returns one-element list and not scalar,
>>> thus making gitweb_check_feature always return list. Updated comment
>>> to explain that part.
>>
>> I do not understand what you are fixing.
>>
>> sub A { return (1); }
>> sub B { return 1; }
>>
>> Don't they quack the same way?
>
> Well, that is just nitpicking. gitweb_check_feature returns list if feature
> is not overridable, so I made it that it always returns list.
Then I'm not sure if Aneesh Kumar patch I replied to is really necessary.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.499824
^ permalink raw reply
* Re: [PATCH] git-rev-list(1): group options; reformat; document more options
From: Jonas Fonseca @ 2006-09-01 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List, Timo Hirvonen
In-Reply-To: <7vsljc78m9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Thu, Aug 31, 2006:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Fri, 1 Sep 2006, Jonas Fonseca wrote:
> >
> >> [The "-r" and "-t" option] do not seem to make sense for
> >> git-rev-list, however if you pass either to git-log, the output
> >> seems to make room for a diff, adding one extra newline, but
> >> without appending any diff.
> >
> > Ahh. I think that a "-r" without any other request for patches (or
> > "--name-status" or similar) should probably imply "--raw". At least
> > that was how it historically worked..
:set paste
commit 17985627455901b6ae3a471b67d46239463cebb5
Author: Timo Hirvonen <tihirvon@gmail.com>
Date: Tue Jun 27 16:27:51 2006 +0300
log --raw: Don't descend into subdirectories by default
Only do so when -r is given.
> > Anyway, _if_ it ever worked (and I think it did, but I'm way too lazy to
> > bother checking), this may have been broken by the extensive diff option
> > cleanups by Timo in June. Timo? Junio?
>
> I think it did too. I am kind of surprised that nobody noticed
> and t4013 test (which was done specifically to catch potential
> behaviour change by Timo's patch) did not check for this
> particular case.
commit 0e677e1a6b0d1c0e848ed19d18dda1c3c797c75e
Author: Timo Hirvonen <tihirvon@gmail.com>
Date: Sat Jun 24 20:25:08 2006 +0300
DIFF_FORMAT_RAW is not default anymore
diff_setup() used to initialize output_format to DIFF_FORMAT_RAW. Now
the default is 0 (no output) so don't compare against DIFF_FORMAT_RAW to
see if any diff format command line flags were given.
:set nopaste
So they are working as intended. I'll look into updating the patch.
BTW, --author=timo made this very easy. ;)
--
Jonas Fonseca
--
VGER BF report: U 0.5
^ permalink raw reply
* [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-01 23:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609011129270.27779@g5.osdl.org>
When reusing data from an existing pack and from a new style
loose objects, we used to just copy it staight into the
resulting pack. Instead make sure they are not corrupt, but
do so only when we are not streaming to stdout, in which case
the receiving end will do the validation either by unpacking
the stream or by constructing the .idx file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 1 Sep 2006, A Large Angry SCM wrote:
>>
>> Unfortunately, the zlib CRC is of the _uncompressed_ data [1], so
>> inflating the stream is still necessary to check for corruption.
>
> I don't think that is unfortunate.
>
> We really should inflate the stream anyway, since not only inflating it,
> but also applying any deltas to the base object is really the only way to
> verify its correctness for a delta thing. Otherwise, the SHA1 of the base
> could be totally corrupt.
>
> And once you inflate it and apply all deltas, you obviously also get the
> full SHA1 check, so you're _really_ safe.
>
> So let's do the really safe thing first, and see if it actually results in
> any problems.
So here is an attempt to do this.
builtin-pack-objects.c | 64 +++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 46f524d..10ba866 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -65,6 +65,7 @@ static unsigned char pack_file_sha1[20];
static int progress = 1;
static volatile sig_atomic_t progress_update;
static int window = 10;
+static int pack_to_stdout;
/*
* The object names in objects array are hashed with this hashtable,
@@ -242,6 +243,55 @@ static int encode_header(enum object_typ
return n;
}
+static int revalidate_one(struct object_entry *entry,
+ void *data, char *type, unsigned long size)
+{
+ unsigned char hdr[50];
+ int hdrlen;
+ unsigned char sha1[20];
+
+ if (!data)
+ return -1;
+ if (size != entry->size)
+ return -1;
+ write_sha1_file_prepare(data, size, type, sha1, hdr, &hdrlen);
+ free(data);
+ if (hashcmp(sha1, entry->sha1))
+ return -1;
+ return 0;
+}
+
+/*
+ * we are going to reuse the existing pack entry data. make
+ * sure it is not corrupt.
+ */
+static int revalidate_pack_entry(struct object_entry *entry)
+{
+ void *data;
+ char type[20];
+ unsigned long size;
+ struct pack_entry e;
+
+ e.p = entry->in_pack;
+ e.offset = entry->in_pack_offset;
+
+ /* the caller has already called use_packed_git() for us */
+ data = unpack_entry_gently(&e, type, &size);
+ return revalidate_one(entry, data, type, size);
+}
+
+static int revalidate_loose_object(struct object_entry *entry,
+ unsigned char *map,
+ unsigned long mapsize)
+{
+ /* we already know this is a loose object with new type header. */
+ void *data;
+ char type[20];
+ unsigned long size;
+ data = unpack_sha1_file(map, mapsize, type, &size);
+ return revalidate_one(entry, data, type, size);
+}
+
static unsigned long write_object(struct sha1file *f,
struct object_entry *entry)
{
@@ -276,6 +326,9 @@ static unsigned long write_object(struct
map = map_sha1_file(entry->sha1, &mapsize);
if (map && !legacy_loose_object(map)) {
/* We can copy straight into the pack file */
+ if (revalidate_loose_object(entry, map, mapsize))
+ die("corrupt loose object %s",
+ sha1_to_hex(entry->sha1));
sha1write(f, map, mapsize);
munmap(map, mapsize);
written++;
@@ -286,7 +339,7 @@ static unsigned long write_object(struct
munmap(map, mapsize);
}
- if (! to_reuse) {
+ if (!to_reuse) {
buf = read_sha1_file(entry->sha1, type, &size);
if (!buf)
die("unable to read %s", sha1_to_hex(entry->sha1));
@@ -319,6 +372,9 @@ static unsigned long write_object(struct
datalen = find_packed_object_size(p, entry->in_pack_offset);
buf = (char *) p->pack_base + entry->in_pack_offset;
+
+ if (revalidate_pack_entry(entry))
+ die("corrupt delta in pack %s", sha1_to_hex(entry->sha1));
sha1write(f, buf, datalen);
unuse_packed_git(p);
hdrlen = 0; /* not really */
@@ -1163,7 +1219,7 @@ static void prepare_pack(int window, int
find_deltas(sorted_by_type, window+1, depth);
}
-static int reuse_cached_pack(unsigned char *sha1, int pack_to_stdout)
+static int reuse_cached_pack(unsigned char *sha1)
{
static const char cache[] = "pack-cache/pack-%s.%s";
char *cached_pack, *cached_idx;
@@ -1247,7 +1303,7 @@ int cmd_pack_objects(int argc, const cha
{
SHA_CTX ctx;
char line[40 + 1 + PATH_MAX + 2];
- int depth = 10, pack_to_stdout = 0;
+ int depth = 10;
struct object_entry **list;
int num_preferred_base = 0;
int i;
@@ -1367,7 +1423,7 @@ int cmd_pack_objects(int argc, const cha
if (progress && (nr_objects != nr_result))
fprintf(stderr, "Result has %d objects.\n", nr_result);
- if (reuse_cached_pack(object_list_sha1, pack_to_stdout))
+ if (reuse_cached_pack(object_list_sha1))
;
else {
if (nr_result)
--
1.4.2.ga2654
--
VGER BF report: U 0.5
^ permalink raw reply related
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-02 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveo741tc.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 1 Sep 2006, Junio C Hamano wrote:
>
> [...] Instead make sure they are not corrupt, but
> do so only when we are not streaming to stdout, [...]
Hmm. I see you making pack_to_stdout available to those functions, but I
don't actually see you using it - looks like you revalidate regardless.
Which is safe, of course, but it doesn't match your description ;)
Linus
--
VGER BF report: H 0.0110285
^ permalink raw reply
* Re: [PATCH] Rewrite branch in C and make it a builtin.
From: Shawn Pearce @ 2006-09-02 1:08 UTC (permalink / raw)
To: krh, Junio C Hamano; +Cc: git
In-Reply-To: <1156562127979-git-send-email-krh@redhat.com>
Kristian H??gsberg <krh@redhat.com> wrote:
> A more or less straight port to C of the shell script version.
[snip]
> +static void create_reflog(struct ref_lock *lock)
I'm attaching a patch to the reflog code which introduces a new
force_log option. You can use set this after you lock the ref
but before writing it, provided that the user supplied -l on
the command line.
This completely replaces the create_reflog function with common code.
I apologize for taking so long to get around to this but I've been
busy with other stuff lately. :-)
-- 8> --
Add force_log flag to ref_lock to create logs when necessary.
Callers of lock_ref_sha1 or lock_any_ref_for_update may now set
lck->force_log = 1 if they want to create the associated reflog
during write_ref_sha1 if the log is missing.
If set this will override a false setting of the configuration
parameter core.logAllRefUpdates and create a missing log, at which
point future updates to the same ref would be logged as the log
is present.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
refs.c | 2 +-
refs.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index aab14fc..b29e2f4 100644
--- a/refs.c
+++ b/refs.c
@@ -361,7 +361,7 @@ static int log_ref_write(struct ref_lock
char *logrec;
const char *committer;
- if (log_all_ref_updates) {
+ if (log_all_ref_updates || lock->force_log) {
if (safe_create_leading_directories(lock->log_file) < 0)
return error("unable to create directory for %s",
lock->log_file);
diff --git a/refs.h b/refs.h
index 553155c..d4798c9 100644
--- a/refs.h
+++ b/refs.h
@@ -7,7 +7,8 @@ struct ref_lock {
struct lock_file *lk;
unsigned char old_sha1[20];
int lock_fd;
- int force_write;
+ int force_write; /* force creating ref if not present */
+ int force_log; /* force creating log if not present */
};
/*
--
1.4.2.ga2654
--
VGER BF report: U 0.5
^ permalink raw reply related
* VGER BF report?
From: Johannes Schindelin @ 2006-09-02 1:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609011721390.27779@g5.osdl.org>
> VGER BF report: H 0.0110285
What is this?
--
VGER BF report: H 0.00947004
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-02 1:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609011721390.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 1 Sep 2006, Junio C Hamano wrote:
>>
>> [...] Instead make sure they are not corrupt, but
>> do so only when we are not streaming to stdout, [...]
>
> Hmm. I see you making pack_to_stdout available to those functions, but I
> don't actually see you using it - looks like you revalidate regardless.
>
> Which is safe, of course, but it doesn't match your description ;)
Oops, that was a thinko. My previous crappoid had
if (pack_to_stdout)
return 0;
at the beginning of revalidate function.
--
VGER BF report: U 0.499951
^ permalink raw reply
* Re: Mozilla .git tree
From: Shawn Pearce @ 2006-09-02 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7vr6yw58xp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Step 3. Work on integrating partial mmap() support with Shawn.
> This is more or less orthogonal to 4GB ceiling (people
> would hit mmap() limit even with a 1.5GB pack), but I
> suspect it would be necessary to be able to tell where
> the end of each pack entry is cheaply to implement
> this.
I was just getting ready to move my partial mmap support over from
fast-import.
Although I did the implementation a little differently in fast-import
than what I think I'll do in core Git. In fast-import store a
hashtable in memory of all objects in the pack but I chose not to
store the ending offset (or compressed length) and instead just
guess about where the object ends. I did that to save 4 bytes of
memory per object. :-)
Its necessary to know where the object ends to ensure that your
current mapping (or any remapping you are about to do) covers the
entire object before you start deflating. Otherwise you might
have to remap the pack in the middle of the inflate operation.
(Of course you might need to do this anyway if the compressed object
is larger than your default mapping unit.)
What I did in fast-import was give inflate whatever was left in
the current mapping; then if I got a Z_OK or Z_BUF_ERROR back from
inflate I move the mapping to the next 128 MiB chunk and reset my
z_stream's next_in/avail_in accordingly, then recall inflate.
No I didn't performance test it to see how frequently I'm mapping
a pack multiple times to get one object. But I'm going to stick my
neck out and say that most objects probably don't have a compressed
length exceeding 128 MiB so we're talking one remap that we would
have had to do anyway if the object spanned over the end of the
current mapping. If the object's starting offset was completely
outside of the current mapping then I rounded the offset down to
the page size (from getpagesize) and remapped; therefore we also
probably only do one remap on objects needing it.
But having the length or ending offset in the index will help with
copying the object during a repack as well as prevent us from needing
to guess during accesses. So good news indeed that you are adding
it to the index.
--
Shawn.
--
VGER BF report: U 0.5
^ permalink raw reply
* Re: Mozilla .git tree
From: Shawn Pearce @ 2006-09-02 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7vr6yw58xp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[snip]
> +A new style .idx file begins with a signature, "\377tOc", and a
> +version number as a 4-byte network byte order integer. The version
> +of this implementation is 2.
Ick. I understand why you did this (and thanks for such a good
explanation of it by the way) but what a horrible signature number
and way to wedge in a version number.
>From now on I propose that if we write a file - especially a binary
file - to disk that we always include a 4 byte version number into
the header of the file. Then we can avoid trying to wedge this into
the file after the fact when some worthwhile improvement requires
changing the format.
I think we probably should have done this when the binary headers
were introduced into loose objects. Would 4 bytes of file format
version number with an (initial version number which wasn't 0x78
in byte 0 and failed the % 31 test) really have hurt that much in
a loose object?
[snip]
> + . 4-byte network byte order integer, recording the location of the
> + next object in the main toc table.
Why not just the 4 byte object entry length? To load an object we
have to go find the next object in the idx file so we can compute
the offset difference. On very large packs (e.g. the Mozilla pack)
the index is 46 MiB. The jump across the index could be the entire
thing from back to front just to compute the size of an object when
the fan-out table and the binary search process really only poked
the tail end of the index when searching for the entry. So we're
demand paging in the front of the index just to compute a length
Sure the scheme you outlined allows a 64 bit difference but
uncompressed objects already can't be larger than 2**32-1 and we
could just as easily move that limit down to say 2**32-16 to leave
room for the object header and zlib header.
--
Shawn.
--
VGER BF report: U 0.5
^ 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