* Life, wheel-smashed
From: Lawrence Cunningham @ 2006-07-17 18:39 UTC (permalink / raw)
To: git-commits-head-owner
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATED cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rate3
$372,000.00 at a 3.90,% variable-rateI
$492,000.00 at a 3.21,% interest-onlyZ
$248,000.00 at a 3.36,% fixed-rateE
$198,000.00 at a 3.55,% variable-rate1
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://C5VFQSW.jokip.com
observation. But the stupid orderlies, who had spent their time during the
Buzzard. If you only knew, Buzzard, that I took your advice this time. "This
on the right there was a slight breeze, and a few steps later he saw a
"I know, I know, I've heard all about your affairs."
familiar--that was the smell that filled the city on the days that the north
obviously was incapable of floating up and dancing in the air, the way so
he thought. How am I going to crawl with it? A mile on all fours. All right,
sparse thickets of willows, and the horizon, beyond the hills, was filled
"Want some?" he offered, wiping the neck of the flask. "For courage?"
the contrary .. . his strength, perhaps? No, not strength. But what then?
it, it's hot! And this is so early in the morning, I can imagine what it
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Geert Bosch @ 2006-07-17 19:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171804030.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Jul 17, 2006, at 12:05, Johannes Schindelin wrote:
>> Not for pack-files, though. You may have a half-gigabyte pack-
>> file, and
>> only use a small small fraction of it.
>
> Right.
>
>> (You also never really rename them, so windows should be fine for
>> that
>> case)
>
> So we could introduce a second mmap() which is normally the same as
> mmap(), except for windows, where it is a rename() and unlink() safe
> version of mmap() by reading the thing into RAM. Not very pretty.
Or we can avoid doing an mmap of the entire pack file, and instead
try to be somewhat smart on limiting the size of the mmap's.
This might be sufficient to help Windows and also solve the
issue of finding contiguous address space for large packs on
32-bit systems.
-Geert
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Alex Riesen @ 2006-07-17 20:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0607171055230.15611@evo.osdl.org>
Linus Torvalds, Mon, Jul 17, 2006 19:56:04 +0200:
> > So we could introduce a second mmap() which is normally the same as
> > mmap(), except for windows, where it is a rename() and unlink() safe
> > version of mmap() by reading the thing into RAM. Not very pretty.
>
> Well, not too ugly either.
>
> Imagine having a "map_packfile()" interface, and letting different targets
> just implement their own version. That doesn't sound too bad, does it?
>
Maybe the patch below will at least help to identify the place where
the interface could be used. It's a bit more than packfiles.
I use it since march (I really meant to post it, but probably forgot).
But careful, it has an ugly piece in git-compat-util.h, which probably
makes the patch only useful on cygwin and nowhere else (is there any
other platform which has NO_MMAP defined?).
---
Makefile | 2 +-
compat/realmmap.c | 26 ++++++++++++++++++++++++++
diff.c | 4 ++--
git-compat-util.h | 10 ++++++++--
sha1_file.c | 24 ++++++++++++------------
5 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/Makefile b/Makefile
index 01fb9cf..f16b466 100644
--- a/Makefile
+++ b/Makefile
@@ -432,7 +432,7 @@ ifdef NO_SETENV
endif
ifdef NO_MMAP
COMPAT_CFLAGS += -DNO_MMAP
- COMPAT_OBJS += compat/mmap.o
+ COMPAT_OBJS += compat/mmap.o compat/realmmap.o
endif
ifdef NO_IPV6
ALL_CFLAGS += -DNO_IPV6
diff --git a/compat/realmmap.c b/compat/realmmap.c
new file mode 100644
index 0000000..8f26641
--- /dev/null
+++ b/compat/realmmap.c
@@ -0,0 +1,26 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include <sys/mman.h>
+#include "../git-compat-util.h"
+
+#undef mmap
+#undef munmap
+
+void *realmmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
+{
+ if (start != NULL || !(flags & MAP_PRIVATE)) {
+ errno = ENOTSUP;
+ return MAP_FAILED;
+ }
+ start = mmap(start, length, prot, flags, fd, offset);
+ return start;
+}
+
+int realmunmap(void *start, size_t length)
+{
+ return munmap(start, length);
+}
+
+
diff --git a/diff.c b/diff.c
index 8b44756..831bf82 100644
--- a/diff.c
+++ b/diff.c
@@ -1094,7 +1094,7 @@ int diff_populate_filespec(struct diff_f
fd = open(s->path, O_RDONLY);
if (fd < 0)
goto err_empty;
- s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
+ s->data = realmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (s->data == MAP_FAILED)
goto err_empty;
@@ -1126,7 +1126,7 @@ void diff_free_filespec_data(struct diff
if (s->should_free)
free(s->data);
else if (s->should_munmap)
- munmap(s->data, s->size);
+ realmunmap(s->data, s->size);
s->should_free = s->should_munmap = 0;
s->data = NULL;
free(s->cnt_data);
diff --git a/git-compat-util.h b/git-compat-util.h
index 93f5580..503b8e4 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -46,22 +46,28 @@ extern void set_error_routine(void (*rou
#ifdef NO_MMAP
-#ifndef PROT_READ
+#include <sys/mman.h>
+/*#ifndef PROT_READ
#define PROT_READ 1
#define PROT_WRITE 2
#define MAP_PRIVATE 1
#define MAP_FAILED ((void*)-1)
-#endif
+#endif*/
#define mmap gitfakemmap
#define munmap gitfakemunmap
extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
extern int gitfakemunmap(void *start, size_t length);
+extern void *realmmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
+extern int realmunmap(void *start, size_t length);
+
#else /* NO_MMAP */
#include <sys/mman.h>
+#define realmmap mmap
+#define realmunmap munmap
#endif /* NO_MMAP */
#ifdef NO_SETENV
diff --git a/sha1_file.c b/sha1_file.c
index e666aec..38ab710 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -331,14 +331,14 @@ static void read_info_alternates(const c
close(fd);
return;
}
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
return;
link_alt_odb_entries(map, map + st.st_size, '\n', relative_base, depth);
- munmap(map, st.st_size);
+ realmunmap(map, st.st_size);
}
void prepare_alt_odb(void)
@@ -394,7 +394,7 @@ static int check_packed_git_idx(const ch
return -1;
}
idx_size = st.st_size;
- idx_map = mmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ idx_map = realmmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (idx_map == MAP_FAILED)
return -1;
@@ -439,7 +439,7 @@ static int unuse_one_packed_git(void)
}
if (!lru)
return 0;
- munmap(lru->pack_base, lru->pack_size);
+ realmunmap(lru->pack_base, lru->pack_size);
lru->pack_base = NULL;
return 1;
}
@@ -476,7 +476,7 @@ int use_packed_git(struct packed_git *p)
}
if (st.st_size != p->pack_size)
die("packfile %s size mismatch.", p->pack_name);
- map = mmap(NULL, p->pack_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, p->pack_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
die("packfile %s cannot be mapped.", p->pack_name);
@@ -511,7 +511,7 @@ struct packed_git *add_packed_git(char *
/* do we have a corresponding .pack file? */
strcpy(path + path_len - 4, ".pack");
if (stat(path, &st) || !S_ISREG(st.st_mode)) {
- munmap(idx_map, idx_size);
+ realmunmap(idx_map, idx_size);
return NULL;
}
/* ok, it looks sane as far as we can check without
@@ -676,7 +676,7 @@ static void *map_sha1_file_internal(cons
*/
sha1_file_open_flag = 0;
}
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
return NULL;
@@ -1220,7 +1220,7 @@ int sha1_object_info(const unsigned char
*sizep = size;
}
inflateEnd(&stream);
- munmap(map, mapsize);
+ realmunmap(map, mapsize);
return status;
}
@@ -1246,7 +1246,7 @@ void * read_sha1_file(const unsigned cha
map = map_sha1_file_internal(sha1, &mapsize);
if (map) {
buf = unpack_sha1_file(map, mapsize, type, size);
- munmap(map, mapsize);
+ realmunmap(map, mapsize);
return buf;
}
reprepare_packed_git();
@@ -1543,7 +1543,7 @@ int write_sha1_to_fd(int fd, const unsig
if (buf) {
retval = write_buffer(fd, buf, objsize);
- munmap(buf, objsize);
+ realmunmap(buf, objsize);
return retval;
}
@@ -1726,7 +1726,7 @@ int index_fd(unsigned char *sha1, int fd
buf = "";
if (size)
- buf = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+ buf = realmmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (buf == MAP_FAILED)
return -1;
@@ -1740,7 +1740,7 @@ int index_fd(unsigned char *sha1, int fd
ret = 0;
}
if (size)
- munmap(buf, size);
+ realmunmap(buf, size);
return ret;
}
--
1.4.1.gb944
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-17 20:32 UTC (permalink / raw)
Cc: git
In-Reply-To: <17595.48003.145000.414361@lapjr.intranet.kiel.bmiag.de>
On 7/17/06, Juergen Ruehle <j.ruehle@bmiag.de> wrote:
> Johannes Schindelin writes:
> > > > It is not Cygwin really. It's windows. You can't rename or delete an
> > > > open or mmapped file in that thing.
> > >
> > > And GIT's workaround is to read the whole file into memory and close
> > > it after that? Uh-oh.
> >
> > If you have a better idea (which does not make git source code ugly), go
> > ahead, write a patch.
>
> On several boxes I've tested the mmap code passes the tests on NTFS.
On me, it failed me on git-apply with more than 1 patches on
the commandline.
git-apply with 1 patch on the commandline passed, with two, failed.
git-apply with two patches on commandline is the simplest
testcase that exposes this problem, AFAIK.
Yakov
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-17 21:31 UTC (permalink / raw)
To: Geert Bosch; +Cc: Johannes Schindelin, Florian Weimer, Git Mailing List
In-Reply-To: <1F90D448-5347-4CEB-80DE-3CC86C1CC16F@adacore.com>
On Mon, 17 Jul 2006, Geert Bosch wrote:
>
> Or we can avoid doing an mmap of the entire pack file, and instead
> try to be somewhat smart on limiting the size of the mmap's.
> This might be sufficient to help Windows and also solve the
> issue of finding contiguous address space for large packs on
> 32-bit systems.
Well, the thing is, you really _do_ want to mmap as much as possible of
the pack-file as possible, if mmap() works.
So even with large pack-files, you do want to mmap a huge chunk at a time,
even if it turns out that you only need a very small part of it.
For example, the commit data is at the very beginning of the pack-file, so
if you only look at the history, you only look at a very small part of the
pack-file, but you should not have to know how much you'll need ahead of
time, so you'd still want the pack-file operations to act in a way that is
efficient for the general case (which is to mmap as much as possible).
So yes, we'll need to have some chunking layer at some point (when people
have gigabyte pack-files) but I think that's a totally separate issue from
the fact that we _do_ actually want mmap() (the _real_ kind of mmap) for
pack-files.
Linus
^ permalink raw reply
* [PATCH] Trivial path optimization test
From: Alex Riesen @ 2006-07-17 22:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0607140828250.5623@g5.osdl.org>
Linus Torvalds, Fri, Jul 14, 2006 17:39:24 +0200:
> > > Btw, I'm actually surprised that my path simplification didn't filter out
> > > the "." and make it mean exactly the same as not giving a path at all. I
> > > thought I had done that earlier, but if you say "-- ." matters, then it
> > > obviously does..
> >
> > In this specific case where I have a whole bunch of commits which don't
> > actually change anything, it definitely does make a difference...
>
> Yes, I'm looking at "get_pathspec()", and noting that it really isn't able
> to optimize away the ".".
>
> It does turn it into an empty string (which is correct - git internally
> does _not_ ever understand the notion of "." as the current working
> directory), but it doesn't ever do the optimization of noticing that a
> pathspec that consists solely of an empty string is "equivalent" to an
> empty pathspec.
>
> Which is exactly what you _want_ in this case, of course, but maybe we
> should add a test-case for that, so that we never do that trivial
> optimization by mistake.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
...
> Anybody want to write that as a test, verify it, and send Junio a patch?
>
> Linus
So here it is.
t/t6004-rev-list-path-optim.sh | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/t/t6004-rev-list-path-optim.sh b/t/t6004-rev-list-path-optim.sh
new file mode 100755
index 0000000..5182dbb
--- /dev/null
+++ b/t/t6004-rev-list-path-optim.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='git-rev-list trivial path optimization test'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+echo Hello > a &&
+git add a &&
+git commit -m "Initial commit" a
+'
+
+test_expect_success path-optimization '
+ commit=$(echo "Unchanged tree" | git-commit-tree "HEAD^{tree}" -p HEAD) &&
+ test $(git-rev-list $commit | wc -l) = 2 &&
+ test $(git-rev-list $commit -- . | wc -l) = 1
+'
+
+test_done
--
1.4.1.gb944
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Juergen Ruehle @ 2006-07-17 22:43 UTC (permalink / raw)
To: Yakov Lerner
In-Reply-To: <f36b08ee0607171332k1da1ef77j352b31c78039d06c@mail.gmail.com>
Yakov Lerner writes:
> On me, it failed me on git-apply with more than 1 patches on
> the commandline.
>
> git-apply with 1 patch on the commandline passed, with two, failed.
>
> git-apply with two patches on commandline is the simplest
> testcase that exposes this problem, AFAIK.
In that case tests 4109 and 4110 should fail, shouldn't they? They
succed for me on NTFS (and fail on other FS). But anyway, I did some
quick performance check and the NO_MMAP code path seems to be as fast
as the mmap one (even much faster in some cases). So the combination
of windows' memory management and git mmap usage doesn't seem so hot
(especially considering the fact that git runs about twice as fast on
FAT32 for me).
jr
^ permalink raw reply
* Forget about it and take pleasure every night!
From: Boston @ 2006-07-18 0:32 UTC (permalink / raw)
To: gord
Yo! Every day thousands of guys have this problem. You can stand out from the crowd. Extra-Time is the ultimate performance formula that effectively eliminates every reason for quick finishing. Everything has its time, and climax in bed shouldn't also happen too soon. All you need is here: http://polerty.com/dll/get/ Gain the enormous sensual vibe in your relationships - no frustration!
^ permalink raw reply
* [PATCH] cvsexportcommit - add -a (add author line) flag, cleanup warnings
From: Martin Langhoff @ 2006-07-18 2:22 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
This patch adds support for -a which will add an "Author: " line, and possibly
a "Committer: " line to the bottom of the commit message for CVS.
The commit message parser is now a little bit better, and some warnings
have been cleaned up.
---
Documentation/git-cvsexportcommit.txt | 6 +++-
git-cvsexportcommit.perl | 50 +++++++++++++++++++++++++--------
2 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 27ac72d..b689c1b 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a commit to
SYNOPSIS
--------
-'git-cvsexportcommit' [-h] [-v] [-c] [-p] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+'git-cvsexportcommit' [-h] [-v] [-c] [-p] [-a] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
@@ -39,6 +39,10 @@ OPTIONS
Be pedantic (paranoid) when applying patches. Invokes patch with
--fuzz=0
+-a::
+ Add authorship information. Adds Author line, and Committer (if
+ different from Author) to the message.
+
-f::
Force the merge even if the files are not up to date.
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 5d13a54..99b3dc3 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -16,9 +16,9 @@ unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR
die "GIT_DIR is not defined or is unreadable";
}
-our ($opt_h, $opt_p, $opt_v, $opt_c, $opt_f, $opt_m );
+our ($opt_h, $opt_p, $opt_v, $opt_c, $opt_f, $opt_a, $opt_m );
-getopts('hpvcfm:');
+getopts('hpvcfam:');
$opt_h && usage();
@@ -29,7 +29,6 @@ our ($tmpdir, $tmpdirname) = tempdir('gi
TMPDIR => 1,
CLEANUP => 1);
-print Dumper(@ARGV);
# resolve target commit
my $commit;
$commit = pop @ARGV;
@@ -53,12 +52,32 @@ if (@ARGV) {
# find parents from the commit itself
my @commit = safe_pipe_capture('git-cat-file', 'commit', $commit);
my @parents;
-foreach my $p (@commit) {
- if ($p =~ m/^$/) { # end of commit headers, we're done
- last;
+my $committer;
+my $author;
+my $stage = 'headers'; # headers, msg
+my $title;
+my $msg = '';
+
+foreach my $line (@commit) {
+ chomp $line;
+ if ($stage eq 'headers' && $line eq '') {
+ $stage = 'msg';
+ next;
}
- if ($p =~ m/^parent (\w{40})$/) { # found a parent
- push @parents, $1;
+
+ if ($stage eq 'headers') {
+ if ($line =~ m/^parent (\w{40})$/) { # found a parent
+ push @parents, $1;
+ } elsif ($line =~ m/^author (.+) \d+ \+\d+$/) {
+ $author = $1;
+ } elsif ($line =~ m/^committer (.+) \d+ \+\d+$/) {
+ $committer = $1;
+ }
+ } else {
+ $msg .= $line . "\n";
+ unless ($title) {
+ $title = $line;
+ }
}
}
@@ -84,12 +103,18 @@ if ($parent) {
# grab the commit message
open(MSG, ">.msg") or die "Cannot open .msg for writing";
-print MSG $opt_m;
+if ($opt_m) {
+ print MSG $opt_m;
+}
+print MSG $msg;
+if ($opt_a) {
+ print MSG "\n\nAuthor: $author\n";
+ if ($author ne $committer) {
+ print MSG "Committer: $committer\n";
+ }
+}
close MSG;
-`git-cat-file commit $commit | sed -e '1,/^\$/d' >> .msg`;
-$? && die "Error extracting the commit message";
-
my (@afiles, @dfiles, @mfiles, @dirs);
my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
#print @files;
@@ -233,6 +258,7 @@ foreach my $f (@dfiles) {
}
print "Commit to CVS\n";
+print "Patch: $title\n";
my $commitfiles = join(' ', @afiles, @mfiles, @dfiles);
my $cmd = "cvs commit -F .msg $commitfiles";
--
1.4.1.ga3e6
^ permalink raw reply related
* No trailing newline and bogus conflicts
From: Martin Langhoff @ 2006-07-18 2:39 UTC (permalink / raw)
To: Git Mailing List
Hi!
I am seem to be having problems merging and cherry-picking patches on
files that have no trailing newlines. Not having a trailing newline is
bad style, but some (arguably braindead) languages and text file
formats actually expect it. (Alas, to be burdened with PHP syntax.)
I may be doing something wrong, but I've had two merges in a row where
git seemed to think that there was conflict or different at the bottom
of the file, where there wasn't.
For example if you clone
http://git.catalyst.net.nz/git/moodle.git#mdl-artena-tairawhiti
(~180MB) and you look around these two merges:
bae5c70f0dc97d1c5a59ec2c9278d06f7427db71
bcfc1924516baa48d6e07eb125a1cb4f39d76dfa
you will see that I cherry-picking patches to auth/db/lib.php --
however I forgot one patch and tried to fix things up in a branch and
merge it in. The last line, though identical, was always reported as
"different" between the 2 files when I was resolving bcfc19.
And later, when working on bae5c, I suspect I shouldn't have seen a
conflict, as both sides had changed exactly the same.
Any ideas other than dropping PHP?
martin
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-18 9:15 UTC (permalink / raw)
Cc: git
In-Reply-To: <17596.4771.377000.843941@lapjr.intranet.kiel.bmiag.de>
On 7/17/06, Juergen Ruehle <j.ruehle@bmiag.de> wrote:
> Yakov Lerner writes:
> > On me, it failed me on git-apply with more than 1 patches on
> > the commandline.
> >
> > git-apply with 1 patch on the commandline passed, with two, failed.
> >
> > git-apply with two patches on commandline is the simplest
> > testcase that exposes this problem, AFAIK.
>
> In that case tests 4109 and 4110 should fail, shouldn't they? They
> succed for me on NTFS (and fail on other FS).
Mine FAT32 FS.
Yakov
> But anyway, I did some
> quick performance check and the NO_MMAP code path seems to be as fast
> as the mmap one (even much faster in some cases). So the combination
> of windows' memory management and git mmap usage doesn't seem so hot
> (especially considering the fact that git runs about twice as fast on
> FAT32 for me).
Yakov
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-18 9:38 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607171431010.2478@evo.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> Well, the thing is, you really _do_ want to mmap as much as possible of
> the pack-file as possible, if mmap() works.
Juergen Ruehle <j.ruehle@bmiag.de> wrote:
> I did some
> quick performance check and the NO_MMAP code path seems to be as fast
> as the mmap one (even much faster in some cases). So the combination
> of windows' memory management and git mmap usage doesn't seem so hot
How about making this parameter (do-use-mmap vs not-use-mmap)
a *runtime* parameter ? (Env. var. $GIT_MMAP or $GIT_USE_MMAP ?).
What do you think ? I see two benefits:
(1) much easier to benchmark two methods against each other
(2) will always work on cygwin (automatic fallback to working
method at runtime; say depending on filesystem)
What do you say ? (Only in case when MMAP is enabled at build-time, of course)
Yakov
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-18 10:20 UTC (permalink / raw)
To: Yakov Lerner
Cc: no To-header on input <""@pop.gmx.net>,
Git Mailing List
In-Reply-To: <f36b08ee0607180238i34cde4deib17426f121ae269e@mail.gmail.com>
Hi,
On Tue, 18 Jul 2006, Yakov Lerner wrote:
> How about making this parameter (do-use-mmap vs not-use-mmap)
> a *runtime* parameter ? (Env. var. $GIT_MMAP or $GIT_USE_MMAP ?).
> What do you think ? I see two benefits:
> (1) much easier to benchmark two methods against each other
You will benchmark it only once, right? No need to have this in git for
one-time use.
> (2) will always work on cygwin (automatic fallback to working
> method at runtime; say depending on filesystem)
I think it is too complicated to depend on the filesystem, and too system
specific (but hey, those who submit a patch are more right than
others...).
But an automatic fallback is not feasible: you would try to mmap(), and it
would throw an "Access violation", which is MS speak for "Segmentation
fault".
Besides, if you would be able to detect a failed mmap(), it would be too
late: the rename() or unlink() would already have taken place.
Ciao,
Dscho
^ permalink raw reply
* print errors from git-update-ref
From: Alex Riesen @ 2006-07-18 13:13 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
...otherwise it not clear what happened when update-ref fails.
E.g., git checkout -b a/b/c HEAD would print nothing if refs/heads/a
exists and is a directory (it does return 1, so scripts checking for
return code should be ok).
I'm attaching two patches, because I'm not quite sure where it should
be done: git-checkout is the least intrusive, but only builtin-update-ref.c
has enough info to help user to resolve the problem (errno is ENOTDIR,
which is selfexplanatory). And I happen to use git-update-ref directly
sometimes.
[-- Attachment #2: 0001-update-ref-print-errors-otherwise-it-not-clear-what-happened.txt --]
[-- Type: text/plain, Size: 1049 bytes --]
From 5398f0ee6bab039701912fdaf784792f4cf76afe Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 18 Jul 2006 14:52:15 +0200
Subject: [PATCH] update-ref: print errors
otherwise it not clear what happened
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-update-ref.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 83094ab..ad4a44d 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -50,10 +50,14 @@ int cmd_update_ref(int argc, const char
die("%s: not a valid old SHA1", oldval);
lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL, 0);
- if (!lock)
+ if (!lock) {
+ error("%s: %s", refname, strerror(errno));
return 1;
- if (write_ref_sha1(lock, sha1, msg) < 0)
+ }
+ if (write_ref_sha1(lock, sha1, msg) < 0) {
+ error("%s: %s", refname, strerror(errno));
return 1;
+ }
/* write_ref_sha1 always unlocks the ref, no need to do it explicitly */
return 0;
--
1.4.2.rc1.g22734
[-- Attachment #3: 0001-git-checkout.sh-print-errors-otherwise-it-is-not-clear-what-happened.txt --]
[-- Type: text/plain, Size: 939 bytes --]
From 7ea3177aec909e333bacccd00693f223997e2613 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 18 Jul 2006 15:10:54 +0200
Subject: [PATCH] git-checkout.sh: print errors, otherwise it is not clear what happened
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-checkout.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 5613bfc..7b335e5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -198,7 +198,7 @@ if [ "$?" -eq 0 ]; then
mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$newbranch")
touch "$GIT_DIR/logs/refs/heads/$newbranch"
fi
- git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || exit
+ git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || die "failed to create branch $newbranch"
branch="$newbranch"
fi
[ "$branch" ] &&
--
1.4.2.rc1.g22734
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-18 15:37 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Git Mailing List
In-Reply-To: <f36b08ee0607180238i34cde4deib17426f121ae269e@mail.gmail.com>
On Tue, 18 Jul 2006, Yakov Lerner wrote:
>
> How about making this parameter (do-use-mmap vs not-use-mmap)
> a *runtime* parameter ?
The thing is, there are really two different kinds of users, and one of
them in particular (the pack-file case) shouldn't have the problems under
Windows at all (because the pack-files aren't moved), and have a much
bigger reason to use mmap in the first place (because accesses will be
sparse, so reading the whole file is wasteful).
The other user was the index file, and _that_ one is the one that gets
renamed (to replace the previous index file), and that one is also not
ever read only partially, so using "read()" instead of mmap is much less
of an issue.
So I really think we should just basically always mmap the pack-files (it
should work everywhere), and make NO_MMAP just trigger on the other cases.
Linus
^ permalink raw reply
* [PATCH] upload-pack: fix timeout in create_pack_file
From: Matthias Lederhofer @ 2006-07-18 17:14 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
<yacc> fatal: packfile '../linux-2.6/.git/objects/pack/tmp-7iPJo5'
SHA1 mismatch
<yacc> error: git-fetch-pack: unable to read from git-index-pack
<yacc> error: git-index-pack died with error code 128
<yacc> Any idea what this means?
This happens after ~12 minutes. The problem is that the loop in
upload-pack.c actually sending the pack does not reset the timeout.
I'd guess --timeout is 600 or a bit more on git.kernel.org :)
This does not help for low timeouts with slow clients. If a client is
slow enough so the server is blocked for more time than specified by
timeout the connection will be closed too (e.g. 15kb/s with a timeout
of 30 (git adds 10 extra) is not enough). We should either add a
warning to the man page or try to fix this. I don't know if this can
be fixed not using non-blocking sockets.
Perhaps support for resume would be quite useful too but I've no idea
how hard this is to implement.
A workaround for is to pull a part of the repository first and the
rest later. For example using this:
$ git init-db
$ git fetch URL refs/tags/old-tag:refs/tags/old-tag
$ git fetch URL refs/tags/newer-tag:refs/tags/newer-tag
..
---
upload-pack.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index f6f5a7e..07ecdb4 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -182,6 +182,8 @@ static void create_pack_file(void)
ssize_t sz;
int pe, pu, pollsize;
+ reset_timeout();
+
pollsize = 0;
pe = pu = -1;
--
1.4.2.rc1.ge7a0
^ permalink raw reply related
* [PATCH] Fix t4114 on cygwin
From: Johannes Schindelin @ 2006-07-18 17:46 UTC (permalink / raw)
To: git, junkio
On cygwin, when you try to create a symlink over a directory, you do
not get EEXIST, but EACCES.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 8f7cf44..d924ac3 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2034,7 +2034,7 @@ static void create_one_file(char *path,
return;
}
- if (errno == EEXIST) {
+ if (errno == EEXIST || errno == EACCES) {
/* We may be trying to create a file where a directory
* used to be.
*/
--
1.4.2.rc1.gaf40
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Alex Riesen @ 2006-07-18 18:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yakov Lerner, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607180837260.3386@evo.osdl.org>
On 7/18/06, Linus Torvalds <torvalds@osdl.org> wrote:
> So I really think we should just basically always mmap the pack-files (it
> should work everywhere), and make NO_MMAP just trigger on the other cases.
And while we are at it make a mental note about avoiding platforms with
broken mmap. For instance, QNX6 mmap with MAP_PRIVATE _always_
makes a copy of the whole! file, the stupid thing (they even documented it so!).
The alternative flag, MAP_SHARED, does not work on some filesystems at all.
^ permalink raw reply
* Re: Kernel headers git tree
From: Ingo Oeser @ 2006-07-18 21:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, git
In-Reply-To: <1152900971.3191.76.camel@pmac.infradead.org>
Hi David,
On Friday, 14. July 2006 20:16, David Woodhouse wrote:
> Well, they're all derived from commits in Linus' tree. I could set up
> another mailing list feed script which tracks it, but I'd like to give
> it a while (until I'm happy with the export scripts) first.
Sounds good :-)
Thanks & Regards
Ingo Oeser
^ permalink raw reply
* [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-18 23:25 UTC (permalink / raw)
To: git, junkio
Now, something like
[alias]
pd = -p diff
works as expected.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 537af3a..a969b1b 100644
--- a/git.c
+++ b/git.c
@@ -115,6 +115,12 @@ static int handle_alias(int *argcp, cons
count = split_cmdline(alias_string, &new_argv);
+ if (count > 0 && !strcmp(new_argv[0], "-p")) {
+ setup_pager();
+ count--;
+ new_argv++;
+ }
+
if (count < 1)
die("empty alias for %s", alias_command);
--
1.4.1.g3c58e
^ permalink raw reply related
* :), oval-faced
From: Leona Battle @ 2006-07-19 6:56 UTC (permalink / raw)
To: git-commits-head-owner
Even if you have no erectin problems SOFT CIA2LIS
would help you to make BETTER SEQX MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ERLECTION during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC1OUNT OFER!
http://EMDAeaju1kk92gk7xwwp1ww7jeww.sowtede.com/
=====
flight - how to get from shore to food and back again. For most gulls, it
a shimmering, a trembling, sort of like hot air at noon over a tin roof. It
conversational idiom, through so formidable a barrier. Theodore Sturgeon San
After all, what can those toads do to me? He really didn't have to say
He climbed two thousand feet above the black sea, and without a
apart, either.
By the time he had pulled his beak straight up into the sky he was
fellows from PPS and left at the passageway. Everyone else was waiting, too.
^ permalink raw reply
* Re: Tracking CVS
From: Petr Baudis @ 2006-07-19 12:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606220717of2ba299ta8a38c7d63fd5635@mail.gmail.com>
Dear diary, on Thu, Jun 22, 2006 at 04:17:15PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> On 6/22/06, Petr Baudis <pasky@suse.cz> wrote:
> >Dear diary, on Thu, Jun 22, 2006 at 02:41:16PM CEST, I got a letter
> >where Jon Smirl <jonsmirl@gmail.com> said that...
> >> I'm tracking cvs using this sequence.
> >>
> >> cvs update
> >> cg rm -a
> >> cg commit
> >> cg add -r .
> >> cg commit
> >>
> >> Is there a way to avoid the two commits? If you do the add with out
> >> the intervening commit it just adds the files back.
>
> How about a cg-sync? Tracking cvs (or other SCM) with git is probably
> a common activitiy while you try to convince the other CVS users to
> switch. It is probably worth a little write up in the readme on the
> best way to do it.
I have added and pushed out support for cg-add -a, now it should be
merely a matter of
cg-rm -a && cg-add -a
and I have documented that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Problems using cg to clone Dave Millers repository
From: Panagiotis Issaris @ 2006-07-19 15:35 UTC (permalink / raw)
To: git; +Cc: davem
Hi,
I'm having trouble cloning Dave Millers kernel repository:
takis@issaris:/tmp/a$ cg-clone
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
defaulting to local storage area
Fetching pack (head and objects)...
fatal: unable to connect a socket (Connection refused)
cg-fetch: fetching pack failed
takis@issaris:/tmp/a$ cg-clone
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
Also look at http://kernel.or
error: Couldn't resolve host 'kernel.orobjects' (curl_result = 6,
http_code = 0, sha1 = ae1237750a9178b81d61308f9228f4f92a7402b2)
Getting pack list for
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
Getting pack list for http://kernel.or
error: Couldn't resolve host 'kernel.or'
error: Unable to find 27fd37621255799602d74e94d670ff7a1658d40a under
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
Cannot obtain needed blob 27fd37621255799602d74e94d670ff7a1658d40a
while processing commit 322045cc61d1dae9ff9e9ba2d7d4768fe1b3385d.
Waiting for
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/objects/d3/a269671c4c20a942bda04579d8d0e6ebf82c73
progress: 8 objects, 6468 bytes
cg-fetch: objects fetch failed
takis@issaris:/tmp/a$ git clone
http://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
takis@issaris:/tmp/a$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
fatal: unable to connect a socket (Connection refused)
fetch-pack from
'git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git' failed.
With friendly regards,
Takis
^ permalink raw reply
* Re: Problems using cg to clone Dave Millers repository
From: Panagiotis Issaris @ 2006-07-19 15:55 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git, davem
In-Reply-To: <44BE5143.70005@uhasselt.be>
Hi,
Just wanted to add, that cloning Torvalds' tree works:
takis@issaris:/tmp/a$ cg-clone
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting index for pack 1d309de746f2b624d754622834d93b394bf43488
progress: 0 objects, 1660856 bytes, now fetching 1d309de746f2...
(1660856 bytes)
Panagiotis Issaris wrote:
> [...]
>
> takis@issaris:/tmp/a$ cg-clone
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> defaulting to local storage area
> Fetching head...
> Fetching objects...
> Getting alternates list for
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
> Also look at http://kernel.or
> error: Couldn't resolve host 'kernel.orobjects' (curl_result = 6,
> http_code = 0, sha1 = ae1237750a9178b81d61308f9228f4f92a7402b2)
> Getting pack list for
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
> Getting pack list for http://kernel.or
> error: Couldn't resolve host 'kernel.or'
> error: Unable to find 27fd37621255799602d74e94d670ff7a1658d40a under
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
> Cannot obtain needed blob 27fd37621255799602d74e94d670ff7a1658d40a
> while processing commit 322045cc61d1dae9ff9e9ba2d7d4768fe1b3385d.
> Waiting for
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/objects/d3/a269671c4c20a942bda04579d8d0e6ebf82c73
>
> progress: 8 objects, 6468 bytes
> cg-fetch: objects fetch failed
> [...]
With friendly regards,
Takis
^ permalink raw reply
* Never-seen But without any results… Delight in
From: Gabriela @ 2006-07-19 18:50 UTC (permalink / raw)
To: godard
Hello!
Have more success with women and impress them with your power and stamina in bed
You are just a couple of clicks away from our great prices and handy shipment
Most trusted brands of the world, join the thousands of happy customers
Come on in: http://www.hanchbi.com
The quality is realt high and the prices are the cheapest on the market!
^ 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