* What's in git.git
From: Junio C Hamano @ 2006-07-17 8:29 UTC (permalink / raw)
To: git
Quite a bit of stuff has been merged, and I have tagged the tip
of the master as v1.4.2-rc1, before heading for Ottawa.
Notable changes in the "master" branch includes:
- Merge-base has been improved thanks to a test script by
ALASCM.
- A handful gitweb enhancements and fixes by Alp Toker and
Luben Tuikov.
- git-svn is now out of "contrib/" status.
- Many documentation updates.
- Fixed a performance bug in git-show-branch, which affected
git-merge.
- Fixed a nonsense output from git-fmt-merge-msg when pulling
HEAD from a remote repository, spotted by Linus.
- "git-log --merge" helps the archeology during a conflicted
merge, per request by Linus.
- git-grep boolean expression to allow --and, --or, and --not
is now in "master".
- A few updates to git-daemon by Matthias Lederhofer.
- A handful portability fixes by Pavel Roskin and Shawn Pearce.
- Ref-log updates by Shawn Pearce.
* The 'next' branch, in addition, has these.
- "checkout -f" and "reset --hard" fixes, when the new tree
should have file "foo" and the old tree and/or working tree
has directory there. Earlier we failed to instantiate file
"foo", and did not report an error. Testing is appreciated.
- git-apply fixes that was started by a test script by Eric
Wong. Testing is appreciated on this stuff.
- Perly git by Pasky with help from others.
- Optional autoconf by Jakub Narebski.
- A WIP of merge-recursive by Johannes and Alex Riesen.
- A usability enhancement of format-patch for imap-send users by
Josh Triplett
- A new loose object format support by Linus.
- An update to diff to make --name-only, --name-status,
--check and -s mutually exclusive by Timo Hirvonen.
* The 'pu' branch has an experimental "read-tree --rename" to
teach renames to git-merge-resolve, but currently it fails a
few of its own tests.
I noticed that "git diff" from subdirectories does not seem to
pick up the configuration from $GIT_DIR/config properly. I
suspect that fixing this breakage properly would help us later,
as more and more commands learn to use the configuration
mechanism to store user preferences, and the same fix would be
applicable to them. If somebody can fix this while we are away
this week, that would be wonderful ;-).
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-17 12:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: Florian Weimer, git
In-Reply-To: <20060716223607.GA6023@steel.home>
Florian Weimer wrote:
> And GIT's workaround is to read the whole file into memory and close
> it after that? Uh-oh.
On 7/16/06, Alex Riesen <fork0@t-online.de> wrote:
> Yakov Lerner, Sun, Jul 16, 2006 17:03:49 +0200:
> > Cygwin has mmap. But cygwin's mmap() not good enough for git.
> > What happens is that git does rename() when target file has active mmap().
> > In cygwin, this makes rename() to fail. This is what makes cygwin's
> > mmap unusable for git. (BTW for read-only git access, mmap() will work
> > on cygwin, for what I saw. But attempts to modify index will break).
>
> It is not Cygwin really. It's windows. You can't rename or delete an
> open or mmapped file in that thing.
We have right to expect cygwin to do some effort to emulate the unix
mmap() semantics on top of different semantics of windows memory-mapped files.
Why doesn't cygwin do some effort to detect active mmap()s on the file
before rename and do something like (1) unmap (2) rename the target to temp name
(3) remap. (4) take care of temp file cleanup ? Probably too messy even if
possible. Is it reasonable to expect git to do this mess ?
It probably belongs to the generic cygwin layer anyway.
I did try another kind of workaround, in which I unmapped the target file
before rename. But it didn't work in all situations and was too intrusive
to the git-apply logic. Didn't work.
Regarding the existing workaround (NO_MMAP), well, cygwin is not exactly a
speed champion in many areas. I didn't really notice speed loss with
NO_MMAP, maybe because cygwin loses time here and there anyway ?
Yakov
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-17 12:41 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87d5c4ajlu.fsf@mid.deneb.enyo.de>
Hi,
On Mon, 17 Jul 2006, Florian Weimer wrote:
> * Alex Riesen:
>
> > 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.
But note that we usually use the whole contents of the mmap()ed file
anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: German documentation for git, cogito, gitweb
From: Nico -telmich- Schottelius @ 2006-07-17 13:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git ML
In-Reply-To: <81b0412b0607140631w2ab8f69cm4c83980fcc93d7d7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
Alex Riesen [Fri, Jul 14, 2006 at 03:31:41PM +0200]:
> On 7/14/06, Nico -telmich- Schottelius <nico-linux-git@schottelius.org>
> wrote:
> >If you find error, spelling mistakes, ... whatever in them,
> >please send diff -u to me.
>
> It's very linux centered, but the sad fact of life is the windows domination
> in corporate networks.
Is it really Linux? Should be neutral to unices. But it's still your
point!
> And while I firmly believe that windows will die, it
> hasn't quite happened yet, and a short notice about cygwin version (and
> how the installation there is done) would be useful. I actually am a bit
> surprised git didn't made it into cygwin distribution yet.
>
> The file does not mention gitk nor qgit, nor other visualisation tools.
> Pity.
I never used qgit nor any other visualization tools. I just used
gitk once, but I really like gitweb more.
I would be happy for a section about those tools, perhaps you can
write it?
Nico
--
Latest release: ccollect-0.4.2 (http://unix.schottelius.org/ccollect/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: German documentation for git, cogito, gitweb
From: Alex Riesen @ 2006-07-17 14:04 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Git ML
In-Reply-To: <20060717135416.GE4227@schottelius.org>
On 7/17/06, Nico -telmich- Schottelius <nico-linux-git@schottelius.org> wrote:
> > And while I firmly believe that windows will die, it
> > hasn't quite happened yet, and a short notice about cygwin version (and
> > how the installation there is done) would be useful. I actually am a bit
> > surprised git didn't made it into cygwin distribution yet.
> >
> > The file does not mention gitk nor qgit, nor other visualisation tools.
> > Pity.
>
> I never used qgit nor any other visualization tools. I just used
> gitk once, but I really like gitweb more.
You have a very good imagination, than.
> I would be happy for a section about those tools, perhaps you can
> write it?
I'll give it a try.
^ permalink raw reply
* Re: git diff in subdirectories
From: Matthias Lederhofer @ 2006-07-17 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd1ghbwo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I noticed that "git diff" from subdirectories does not seem to
> pick up the configuration from $GIT_DIR/config properly. I
> suspect that fixing this breakage properly would help us later,
> as more and more commands learn to use the configuration
> mechanism to store user preferences, and the same fix would be
> applicable to them. If somebody can fix this while we are away
> this week, that would be wonderful ;-).
I can think of these ways to fix this:
- Allow git_config() to work in subdirectories.
- It can either change the working directory using
setup_git_directory_gently() and go back to the subdirectory
later.
- Or we add a function to get the full path to the repository. This
could perhaps also be used in setup_git_env() to initialize
git_dir? Otherwise I would just add another function similar to
git_path pointing to the full path instead of .git/. (This is the
way I'd prefer.)
- Fix the it in builtin-diff: change the directory before calling
git_config(). Then we would either need to change the directory
back or add a parameter to init_revisions to get the prefix without
calling setup_git_directory itself. (I think this will change the
least code but wont help other commands.)
Any comments?
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-17 15:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171439270.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 17 Jul 2006, Johannes Schindelin wrote:
>
> But note that we usually use the whole contents of the mmap()ed file
> anyway.
Not for pack-files, though. You may have a half-gigabyte pack-file, and
only use a small small fraction of it.
(You also never really rename them, so windows should be fine for that
case)
Linus
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-17 16:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0607170840280.15611@evo.osdl.org>
Hi,
On Mon, 17 Jul 2006, Linus Torvalds wrote:
> On Mon, 17 Jul 2006, Johannes Schindelin wrote:
> >
> > But note that we usually use the whole contents of the mmap()ed file
> > anyway.
>
> 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.
Ciao,
Dscho
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Juergen Ruehle @ 2006-07-17 16:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171439270.29667@wbgn013.biozentrum.uni-wuerzburg.de>
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.
It is usable for my simple work even on FAT32 with an unlink before
the rename in lockfile.c, but that probably breaks in more involved
scenarios.
jr
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-17 17:10 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Florian Weimer, git
In-Reply-To: <17595.48003.145000.414361@lapjr.intranet.kiel.bmiag.de>
Hi,
On Mon, 17 Jul 2006, Juergen Ruehle 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.
>
> It is usable for my simple work even on FAT32 with an unlink before
> the rename in lockfile.c, but that probably breaks in more involved
> scenarios.
In my not-so-simple tests, it failed. Reproducibly. If I am not mistaken,
your test just does not hit the problem, namely fork()ing after
rename()ing a mmap()ed file.
Now, with the diff changes a few months ago, there are way less fork()s in
the code, that might be one reason you do not hit the wall, but I could
imagine that a "git-read-tree -m -u" still has problems. Note: I did not
test what I just said, but I _did_ test that there are problems with
mmap() when you fork() with the map in use.
Ciao,
Dscho
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Juergen Ruehle @ 2006-07-17 17:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171907080.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> In my not-so-simple tests, it failed. Reproducibly. If I am not mistaken,
> your test just does not hit the problem, namely fork()ing after
> rename()ing a mmap()ed file.
No doubt about that.
But until you post additional test cases, I can continue to claim my
version passes all tests:-)
jr
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-17 17:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171804030.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 17 Jul 2006, Johannes Schindelin wrote:
>
> 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?
Linus
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Martin Waitz @ 2006-07-17 18:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0607171055230.15611@evo.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
hoi :)
On Mon, Jul 17, 2006 at 10:56:04AM -0700, Linus Torvalds wrote:
> Imagine having a "map_packfile()" interface, and letting different targets
> just implement their own version. That doesn't sound too bad, does it?
we'd need something like that anyway if we want to support larger
pack files.
When it is only possible to map a part of the file into memory at a
given time then we have to special case all accesses to the pack file,
too. Or is there an easier way?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* fatal: git-unpack-objects died with error code 128
From: Chris Wedgwood @ 2006-07-17 18:25 UTC (permalink / raw)
To: Git Mailing List
Can anyone suggest what I should be doing to make this work?
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git :history
warning: no common commits
Generating pack...
Done counting 566638 objects.
Deltifying 566638 objects.
100% (566638/566638) done
Unpacking 566638 objects
fatal: unexpected EOF done
fatal: early EOF
fatal: git-unpack-objects died with error code 128
Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
using:
git version 1.4.1
Is there some other way to achieve this?
^ permalink raw reply
* 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
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