* Re: confusion over the new branch and merge config
From: Jakub Narebski @ 2007-01-03 23:02 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8aa486160701021624v69015fbibb81a99177dd7dfc@mail.gmail.com>
Santi Béjar wrote:
> On 1/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano wrote:
>>
>>> Obviously, the local names should matter more when you are doing
>>> local operations. So if you are using mergeLocal to give a
>>> shorthand to "git merge" that does not explicitly say what to
>>> merge, the above discussion does not apply. But if that is the
>>> case, mergeLocal should also not affect the selection of
>>> branches to be merged when "git pull" happens from a remote
>>> either.
>>
>> You can always use remote = ".", and then remote and local branches
>> are the same...
>
> Currently it does not work.
Fact.
I remember that there was proposal of having branch.<name>.remote=.
and branch.<name>.merge=<ref> to make "git pull" on branch <name>
do "git pull . <ref>". There was some discussion about this; perhaps
it was not accepted (or forgotten to be accepted after resolving
discussion).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: preview of "What's cooking" (topics)
From: Juergen Ruehle @ 2007-01-03 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virfopfuo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> - Jürgen's git-status improvements are mostly in 'next' but
> one of them is queued in 'pu', waiting for comments.
Here is a more detailed breakdown of the reasoning behind the
remaining change in (slightly massaged) git-log format. Especially
the usage of 'cached' and 'unstage' might not be that helpful.
==========
Add "cached" to cached content header in status output
Since we direct the user to use git-rm --cached this might be a good way to
clarify it without loosing many words.
diff --git a/wt-status.c b/wt-status.c
index 8696e5b..e6355c6 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -56,7 +56,7 @@ void wt_status_prepare(struct wt_status *s)
static void wt_status_print_cached_header(const char *reference)
{
const char *c = color(WT_STATUS_HEADER);
- color_printf_ln(c, "# Changes to be committed:");
+ color_printf_ln(c, "# Cached changes to be committed:");
if (reference) {
color_printf_ln(c, "# (use \"git reset %s <file>...\" and \"git rm --cached <file>...\" to unstage)", reference);
} else {
==========
Add unstaging hint to status output
If reference commit name is provided advertise git-reset otherwise instruct the
user to use git-rm --cached. The latter case is needed to handle the initial
commit.
Note that git-rm --cached is currently needed even if we have a reference
commit, since git-reset cannot remove freshly added files from the index (yet).
diff --git a/wt-status.c b/wt-status.c
index 82b76d5..8696e5b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -57,6 +57,11 @@ static void wt_status_print_cached_header(const char *reference)
{
const char *c = color(WT_STATUS_HEADER);
color_printf_ln(c, "# Changes to be committed:");
+ if (reference) {
+ color_printf_ln(c, "# (use \"git reset %s <file>...\" and \"git rm --cached <file>...\" to unstage)", reference);
+ } else {
+ color_printf_ln(c, "# (use \"git rm --cached <file>...\" to unstage)");
+ }
color_printf_ln(c, "#");
}
==========
Simplify cached content header in status output
Replace awkward "Added but not yet committed (will commit)" by a simple
"Changes to be committed".
diff --git a/wt-status.c b/wt-status.c
index 1959238..82b76d5 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -56,8 +56,7 @@ void wt_status_prepare(struct wt_status *s)
static void wt_status_print_cached_header(const char *reference)
{
const char *c = color(WT_STATUS_HEADER);
- color_printf_ln(c, "# Added but not yet committed:");
- color_printf_ln(c, "# (will commit):");
+ color_printf_ln(c, "# Changes to be committed:");
color_printf_ln(c, "#");
}
==========
Refactor printing of cached content header of status output
Since this header is printed in two different code paths and the name of the
reference commit will be needed for the future unstaging hint, provide a new
printing function.
diff --git a/wt-status.c b/wt-status.c
index db42738..1959238 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -53,6 +53,14 @@ void wt_status_prepare(struct wt_status *s)
s->untracked = 0;
}
+static void wt_status_print_cached_header(const char *reference)
+{
+ const char *c = color(WT_STATUS_HEADER);
+ color_printf_ln(c, "# Added but not yet committed:");
+ color_printf_ln(c, "# (will commit):");
+ color_printf_ln(c, "#");
+}
+
static void wt_status_print_header(const char *main, const char *sub)
{
const char *c = color(WT_STATUS_HEADER);
@@ -147,8 +155,7 @@ static void wt_status_print_updated_cb(struct diff_queue_struct *q,
if (q->queue[i]->status == 'U')
continue;
if (!shown_header) {
- wt_status_print_header("Added but not yet committed",
- "will commit");
+ wt_status_print_cached_header(s->reference);
s->commitable = 1;
shown_header = 1;
}
@@ -179,8 +186,7 @@ void wt_status_print_initial(struct wt_status *s)
read_cache();
if (active_nr) {
s->commitable = 1;
- wt_status_print_header("Added but not yet committed",
- "will commit");
+ wt_status_print_cached_header(NULL);
}
for (i = 0; i < active_nr; i++) {
color_printf(color(WT_STATUS_HEADER), "#\t");
^ permalink raw reply related
* [PATCH take 2] git-tag: add flag to verify a tag
From: Santi Béjar @ 2007-01-03 23:17 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <877iw4tgff.fsf@gmail.com>
This way "git tag -v $tag" is the UI for git-verify-tag.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Hi *,
But maybe the -v flag should give a similar output as:
$ git branch -v
Then this flag could be -c for check?
This version has a syntax fix (sorry) and a typo fix.
Documentation/git-tag.txt | 7 ++++++-
generate-cmdlist.sh | 1 -
git-tag.sh | 11 ++++++++++-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 48b82b8..5cf114d 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,7 @@ git-tag - Create a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg> | -F <file>]
+'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
<name> [<head>]
'git-tag' -l [<pattern>]
@@ -35,6 +35,8 @@ GnuPG key for signing.
`-d <tag>` deletes the tag.
+`-v <tag>` verifies the gpg signature of the tag.
+
`-l <pattern>` lists tags that match the given pattern (or all
if no pattern is given).
@@ -55,6 +57,9 @@ OPTIONS
-d::
Delete an existing tag with the given name
+-v::
+ Verify the gpg signature of the given tag
+
-l <pattern>::
List tags that match the given pattern (or all if no pattern is given).
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 06c42b0..1de14ea 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -37,7 +37,6 @@ show
show-branch
status
tag
-verify-tag
EOF
while read cmd
do
diff --git a/git-tag.sh b/git-tag.sh
index e1bfa82..c3e4e15 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2005 Linus Torvalds
-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <tagname> [<head>]'
+USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -69,6 +69,14 @@ do
echo "Deleted tag $tag_name."
exit $?
;;
+ -v)
+ shift
+ tag_name="$1"
+ tag=$(git-show-ref --verify --hash -- "refs/tags/$tag_name") ||
+ die "Seriously, what tag are you talking about?"
+ git-verify-tag -v "$tag"
+ exit $?
+ ;;
-*)
usage
;;
--
1.5.0.rc0.g1eb3
^ permalink raw reply related
* git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-03 23:52 UTC (permalink / raw)
To: git
So I'm using git 1.4.1, and I have been experimenting with importing
the KDE sources from Subversion using git-svnimport.
First issue I ran into: On a machine with 4GB of RAM, when I tried to
do a full import, git-svnimport died after 309906 revisions, saying
that it couldn't fork.
Checking `top` and `ps` revealed that there were no git-svnimport
processes doing anything, but all of my 4G of RAM was still marked as
used by the kernel. I had to do sysctl -w vm.drop_caches=3 to get it
to free all the RAM that the svn import had used up.
Now, after that, I tried doing `git-repack -a` because I wanted to see
how small the packed archive would be (before trying to continue
importing the rest of the revisions. There are at least another 100k
revisions that I should be able to import, eventually.)
The repack finished after about nine hours, but when I try to do a
git-verify-pack on it, it dies with this error message:
error: Packfile
.git/objects/pack/pack-540263fe66ab9398cc796f000d52531a5c6f3df3.pack
SHA1 mismatch with itself
I get the same message from git-prune.
Any ideas?
^ permalink raw reply
* Re: [PATCH] Documentation/tutorial: misc updates
From: Horst H. von Brand @ 2007-01-04 0:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <engd5e$8fr$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Horst H. von Brand wrote:
>
> >> +------------------------------------------------
> >> +$ git branch -d experimental
> >> +------------------------------------------------
> >> +
> >> +This command ensures that the changes in the experimental branch are
> >> +already in the current branch.
> >> +
> > Huh? This deletes the branch, it doesn't ensure changes have been saved.
> It ensures that the branch we want to delete is in lineage of
> current branch (otherwise we would have to use -D).
I know. But it doesn't "ensure" anything, the /user/ has to ensure
beforehand that there are no outstanding changes for it to succeed. Fine
distinction, I know. But better be extra clear.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-04 1:59 UTC (permalink / raw)
To: Chris Lee, Junio C Hamano, Shawn Pearce, Sasha Khapyorsky
Cc: Git Mailing List
In-Reply-To: <204011cb0701031552j8292d23v950f828279702d3@mail.gmail.com>
On Wed, 3 Jan 2007, Chris Lee wrote:
>
> So I'm using git 1.4.1, and I have been experimenting with importing
> the KDE sources from Subversion using git-svnimport.
As one single _huge_ import? All the sub-projects together? I have to say,
that sounds pretty horrid.
> First issue I ran into: On a machine with 4GB of RAM, when I tried to
> do a full import, git-svnimport died after 309906 revisions, saying
> that it couldn't fork.
>
> Checking `top` and `ps` revealed that there were no git-svnimport
> processes doing anything, but all of my 4G of RAM was still marked as
> used by the kernel. I had to do sysctl -w vm.drop_caches=3 to get it
> to free all the RAM that the svn import had used up.
I think that was just all cached, and all ok. The reason you didn't see
any git-svnimport was that it had died off already, and all your memory
was just caches. You could just have left it alone, and the kernel would
have started re-using the memory for other things even without any
"drop_caches".
But what you did there didn't make anything worse, it was just likely had
no real impact.
However, it does sound like git-svnimport probably acts like git-cvsimport
used to, and just keeps too much in memory - so it's never going to act
really nicely..
It also looks like git-svnimport never repacks the repo, which is
absolutely horrible for performance on all levels. The CVS importer
repacks every one thousand commits or something like that.
> Now, after that, I tried doing `git-repack -a` because I wanted to see
> how small the packed archive would be (before trying to continue
> importing the rest of the revisions. There are at least another 100k
> revisions that I should be able to import, eventually.)
I suspect you'd have been better off just re-starting, and using something
like
while :
do
git svnimport -l 1000 <...>
.. figure out some way to decide if it's all done ..
git repack -d
done
which would make svnimport act a bit more sanely, and repack
incrementally. That should make both the import much faster, _and_ avoid
any insane big repack at the end (well, you'd still want to do a "git
repack -a -d" at the end to turn the many smaller packs into a bigger one,
but it would be nicer).
However, I don't know what the proper magic is for svnimport to do that
sane "do it in chunks and tell when you're all done". Or even better - to
just make it repack properly and not keep everything in memory.
> The repack finished after about nine hours, but when I try to do a
> git-verify-pack on it, it dies with this error message:
>
> error: Packfile
> .git/objects/pack/pack-540263fe66ab9398cc796f000d52531a5c6f3df3.pack
> SHA1 mismatch with itself
That sounds suspiciously like the bug we had in out POWER sha1
implementation that would generate the wrong SHA1 for any pack-file that
was over 512MB in size, due to an overflow in 32 bits (SHA1 does some
counting in _bits_, so 512MB is 4G _bits_),
Now, I assume you're not on POWER (and we fixed that bug anyway - and I
think long before 1.4.1 too), but I could easily imagine the same bug in
some other SHA1 implementation (or perhaps _another_ overflow at the 1GB
or 2GB mark..). I assume that the pack-file you had was something horrid..
I hope this is with a 64-bit kernel and a 64-bit user space? That should
limit _some_ of the issues. But I would still not be surprised if your
SHA1 libraries had some 32-bit ("unsigned int") or 31-bit ("int") limits
in them somewhere - very few people do SHA1's over huge areas, and even
when you do SHA1 on something like a DVD image (which is easily over any
4GB limit), that tends to be done as many smaller calls to the SHA1
library routines.
Junio - I suspect "pack-check.c" really shouldn't try to do it as one
single humungous "SHA1_Update()" call. It showed one bug on PPC, I
wouldn't be surprised if it's implicated now on some other architecture.
Shawn - does the pack-file-windowing thing already change that? I'm too
lazy to check..
As to who knows how to fix git-svnimport to do something saner, I have no
clue.. Sasha seems to have touched it last. Sasha?
Linus
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Shawn O. Pearce @ 2007-01-04 2:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Lee, Junio C Hamano, Sasha Khapyorsky, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0701031737300.4989@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> Junio - I suspect "pack-check.c" really shouldn't try to do it as one
> single humungous "SHA1_Update()" call. It showed one bug on PPC, I
> wouldn't be surprised if it's implicated now on some other architecture.
It used to do it as one big SHA1_Update() call...
> Shawn - does the pack-file-windowing thing already change that? I'm too
> lazy to check..
But with the mmap window thing in `next` it does it in window
units only. Which the user could configure to be huge, or could
configure to be sane. The default when using mmap() is 32 MiB;
1 MiB when using pread() and git_mmap().
--
Shawn.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Eric Wong @ 2007-01-04 2:33 UTC (permalink / raw)
To: Chris Lee
Cc: Linus Torvalds, Junio C Hamano, Shawn Pearce, Sasha Khapyorsky,
Randal L. Schwartz, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0701031737300.4989@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 3 Jan 2007, Chris Lee wrote:
> > First issue I ran into: On a machine with 4GB of RAM, when I tried to
> > do a full import, git-svnimport died after 309906 revisions, saying
> > that it couldn't fork.
Managing memory with the Perl SVN libraries has been very painful in my
experience.
Part of it is Perl, which (as far as I know) never frees allocated
memory back to the OS (although Perl can reuse the allocated memory for
other things). I'm CC-ing the resident Perl guru on this...
I'm also fairly certain that most higher-level languages have this
problem.
> I suspect you'd have been better off just re-starting, and using something
> like
>
> while :
> do
> git svnimport -l 1000 <...>
> .. figure out some way to decide if it's all done ..
> git repack -d
> done
> However, I don't know what the proper magic is for svnimport to do that
> sane "do it in chunks and tell when you're all done". Or even better - to
> just make it repack properly and not keep everything in memory.
<shameless self-promotion>
git-svn already does this chunking internally
Just set the repack interval to something smaller than 1000;
(--repack=100) if you experience timeouts.
</shameless self-promotion>
--
Eric Wong
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Shawn O. Pearce @ 2007-01-04 2:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Lee, Junio C Hamano, Sasha Khapyorsky, Git Mailing List
In-Reply-To: <20070104020652.GB18206@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> > Junio - I suspect "pack-check.c" really shouldn't try to do it as one
> > single humungous "SHA1_Update()" call. It showed one bug on PPC, I
> > wouldn't be surprised if it's implicated now on some other architecture.
>
> It used to do it as one big SHA1_Update() call...
>
> > Shawn - does the pack-file-windowing thing already change that? I'm too
> > lazy to check..
>
> But with the mmap window thing in `next` it does it in window
> units only. Which the user could configure to be huge, or could
> configure to be sane. The default when using mmap() is 32 MiB;
> 1 MiB when using pread() and git_mmap().
I should also point out that my git-fastimport hack that we used
on the huge Mozilla import may be helpful here. Its _very_ fast
as it goes right to a pack file, but there's no SVN frontend for
it at this time.
--
Shawn.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 2:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Linus Torvalds, Junio C Hamano, Sasha Khapyorsky,
Git Mailing List
In-Reply-To: <20070104023510.GC18206@spearce.org>
On 1/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> I should also point out that my git-fastimport hack that we used
> on the huge Mozilla import may be helpful here. Its _very_ fast
> as it goes right to a pack file, but there's no SVN frontend for
> it at this time.
I would be *really* interested in playing with that. Where do I get it?
^ permalink raw reply
* git completely non-operational w/ curl 7.16.0
From: felix-git @ 2007-01-04 2:31 UTC (permalink / raw)
To: git
I'm using git 1.4.4.3 on x86_64-linux with curl 7.16.0, glibc 2.5, gcc
4.1.1 and binutils 2.17. All of these are as far as I know the current
release versions.
Now, when I try to clone the elinks git repository, this happens:
$ cg clone http://elinks.cz/elinks.git
defaulting to local storage area
Fetching head...
Fetching objects...
*** glibc detected *** git-http-fetch: double free or corruption (fasttop): 0x0000000000552390 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2ae65f64f45e]
/lib64/libc.so.6(__libc_free+0xae)[0x2ae65f650784]
git-http-fetch[0x4041bd]
git-http-fetch[0x404f80]
git-http-fetch[0x403027]
git-http-fetch[0x404454]
/lib64/libc.so.6(__libc_start_main+0x14b)[0x2ae65f60e6cb]
git-http-fetch[0x4029c9]
======= Memory map: ========
00400000-0041e000 r-xp 00000000 00:0d 772197 /tmp/fefix/usr/bin/git-http-fetch
0051d000-0051f000 rw-p 0001d000 00:0d 772197 /tmp/fefix/usr/bin/git-http-fetch
0051f000-0056e000 rw-p 0051f000 00:00 0 [heap]
2ae65eeed000-2ae65ef05000 r-xp 00000000 08:03 12554262 /lib64/ld-2.5.so
2ae65ef05000-2ae65ef06000 rw-p 2ae65ef05000 00:00 0
2ae65ef12000-2ae65ef13000 rw-p 2ae65ef12000 00:00 0
2ae65f004000-2ae65f006000 rw-p 00017000 08:03 12554262 /lib64/ld-2.5.so
2ae65f006000-2ae65f01c000 r-xp 00000000 08:03 14996111 /usr/lib64/libz.so.1.2.3
2ae65f01c000-2ae65f11b000 ---p 00016000 08:03 14996111 /usr/lib64/libz.so.1.2.3
2ae65f11b000-2ae65f11c000 rw-p 00015000 08:03 14996111 /usr/lib64/libz.so.1.2.3
2ae65f11c000-2ae65f26c000 r-xp 00000000 08:03 14996178 /usr/lib64/libcrypto.so.0.9.8
2ae65f26c000-2ae65f36c000 ---p 00150000 08:03 14996178 /usr/lib64/libcrypto.so.0.9.8
2ae65f36c000-2ae65f38f000 rw-p 00150000 08:03 14996178 /usr/lib64/libcrypto.so.0.9.8
2ae65f38f000-2ae65f392000 rw-p 2ae65f38f000 00:00 0
2ae65f392000-2ae65f3cd000 r-xp 00000000 08:03 10667012 /usr/lib64/libcurl.so.4.0.0
2ae65f3cd000-2ae65f4cc000 ---p 0003b000 08:03 10667012 /usr/lib64/libcurl.so.4.0.0
2ae65f4cc000-2ae65f4ce000 rw-p 0003a000 08:03 10667012 /usr/lib64/libcurl.so.4.0.0
2ae65f4ce000-2ae65f4cf000 rw-p 2ae65f4ce000 00:00 0
2ae65f4cf000-2ae65f4ef000 r-xp 00000000 08:03 10667121 /usr/lib64/libexpat.so.0.5.0
2ae65f4ef000-2ae65f5ef000 ---p 00020000 08:03 10667121 /usr/lib64/libexpat.so.0.5.0
2ae65f5ef000-2ae65f5f1000 rw-p 00020000 08:03 10667121 /usr/lib64/libexpat.so.0.5.0
2ae65f5f1000-2ae65f6fe000 r-xp 00000000 08:03 12554263 /lib64/libc-2.5.so
2ae65f6fe000-2ae65f7fe000 ---p 0010d000 08:03 12554263 /lib64/libc-2.5.so
2ae65f7fe000-2ae65f801000 r--p 0010d000 08:03 12554263 /lib64/libc-2.5.so
2ae65f801000-2ae65f803000 rw-p 00110000 08:03 12554263 /lib64/libc-2.5.so
2ae65f803000-2ae65f808000 rw-p 2ae65f803000 00:00 0
2ae65f808000-2ae65f80a000 r-xp 00000000 08:03 12554244 /lib64/libdl-2.5.so
2ae65f80a000-2ae65f90a000 ---p 00002000 08:03 12554244 /lib64/libdl-2.5.so
2ae65f90a000-2ae65f90c000 rw-p 00002000 08:03 12554244 /lib64/libdl-2.5.so
2ae65f90c000-2ae65f90d000 rw-p 2ae65f90c000 00:00 0
2ae65f90d000-2ae65f94e000 r-xp 00000000 08:03 14996177 /usr/lib64/libssl.so.0.9.8
2ae65f94e000-2ae65fa4e000 ---p 00041000 08:03 14996177 /usr/lib64/libssl.so.0.9.8
2ae65fa4e000-2ae65fa54000 rw-p 00041000 08:03 14996177 /usr/lib64/libssl.so.0.9.8
2ae65fa54000-2ae65fa55000 rw-p 2ae65fa54000 00:00 0
2ae65fa55000-2ae65fa5c000 r-xp 00000000 08:03 12554260 /lib64/libnss_compat-2.5.so
2ae65fa5c000-2ae65fb5b000 ---p 00007000 08:03 12554260 /lib64/libnss_compat-2.5.so
2ae65fb5b000-2ae65fb5d000 rw-p 00006000 08:03 12554260 /lib64/libnss_compat-2.5.so
2ae65fb5d000-2ae65fb6e000 r-xp 00000000 08:03 12554257 /lib64/libnsl-2.5.so
2ae65fb6e000-2ae65fc6d000 ---p 00011000 08:03 12554257 /lib64/libnsl-2.5.so
2ae65fc6d000-2ae65fc6f000 rw-p 00010000 08:03 12554257 /lib64/libnsl-2.5.so
2ae65fc6f000-2ae65fc71000 rw-p 2ae65fc6f000 00:00 0
2ae65fc71000-2ae65fc7a000 r-xp 00000000 08:03 12554258 /lib64/libnss_nis-2.5.so
2ae65fc7a000-2ae65fd79000 ---p 00009000 08:03 12554258 /lib64/libnss_nis-2.5.so
2ae65fd79000-2ae65fd7b000 rw-p 00008000 08:03 12554258 /lib64/libnss_nis-2.5.so
2ae65fd7b000-2ae65fd84000 r-xp 00000000 08:03 12554251 /lib64/libnss_files-2.5.so
2ae65fd84000-2ae65fe83000 ---p 00009000 08:03 12554251 /lib64/libnss_files-2.5.so
2ae65fe83000-2ae65fe85000 rw-p 00008000 08:03 12554251 /lib64/libnss_files-2.5.so
2ae65fe85000-2ae65fe92000 r-xp 00000000 08:03 14995967 /usr/lib64/libgcc_s.so.1
2ae65fe92000-2ae65ff91000 ---p 0000d000 08:03 14995967 /usr/lib64/libgcc_s.so.1
2ae65ff91000-2ae65ff92000 rw-p 0000c000 08:03 14995967 /usr/lib64/libgcc_s.so.1
2ae660000000-2ae660021000 rw-p 2ae660000000 00:00 0
2ae660021000-2ae664000000 ---p 2ae660021000 00:00 0
7fff4bba8000-7fff4bbbd000 rwxp 7fff4bba8000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]
error: Request for 1e8f8aa4a60a9651e17347d36a880c35c7179391 aborted
progress: 0 objects, 0 bytes
cg-fetch: objects fetch failed
As you can see this is somewhat undesireable. The double free is line
316 in http-fetch.c:
free(obj_req->url);
If I fix this bug, git still utterly breaks.
$ cg clone http://elinks.cz/elinks.git
defaulting to local storage area
Fetching head...
Fetching objects...
error: Request for 1e8f8aa4a60a9651e17347d36a880c35c7179391 aborted
Getting pack list for http://elinks.cz/elinks.git/
error: Unable to start request
Getting alternates list for http://elinks.cz/elinks.git/
error: Unable to find 1e8f8aa4a60a9651e17347d36a880c35c7179391 under
http://elinks.cz/elinks.git/
Cannot obtain needed object 1e8f8aa4a60a9651e17347d36a880c35c7179391
progress: 0 objects, 0 bytes
cg-fetch: objects fetch failed
$
Now, running the same git/cogito command line on my Gentoo box works,
which only apparently differs in that it ships an older version of curl.
Would someone please fix this?
Thanks,
Felix
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Randal L. Schwartz @ 2007-01-04 2:40 UTC (permalink / raw)
To: Eric Wong
Cc: Chris Lee, Linus Torvalds, Junio C Hamano, Shawn Pearce,
Sasha Khapyorsky, Git Mailing List
In-Reply-To: <20070104023350.GA1194@localdomain>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> Part of it is Perl, which (as far as I know) never frees allocated
Eric> memory back to the OS (although Perl can reuse the allocated memory for
Eric> other things).
It does on Linux, of all things. That's because Linux has a smarter
malloc/free that uses mmap(2) for the large chunks. On Linux, Perl memory
size can apparently grow and shrink nicely. The "old school" advice about
Perl comes from sbrk(2)-driven malloc/free.
Try:
$x[1e6] = "0";
sleep 10; # do a ps here
@x = ();
sleep 30; # do a ps here
and watch the process on Linux. If I'm right, this should show a large
process, then a smaller one.
If you're getting a growing process though, you probably have a circular data
reference. Maybe you have a tree with backpointers, and those backpointers
should have been weakened?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Shawn O. Pearce @ 2007-01-04 2:45 UTC (permalink / raw)
To: Chris Lee
Cc: Linus Torvalds, Junio C Hamano, Sasha Khapyorsky,
Git Mailing List
In-Reply-To: <204011cb0701031836w7d33ca8dh5de08984eec9730d@mail.gmail.com>
Chris Lee <chris133@gmail.com> wrote:
> On 1/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >I should also point out that my git-fastimport hack that we used
> >on the huge Mozilla import may be helpful here. Its _very_ fast
> >as it goes right to a pack file, but there's no SVN frontend for
> >it at this time.
>
> I would be *really* interested in playing with that. Where do I get it?
Its a fork of git.git on repo.or.cz; the gitweb can be seen here:
http://repo.or.cz/w/git/fastimport.git
the clone url is:
git://repo.or.cz/git/fastimport.git
http://repo.or.cz/r/git/fastimport.git
The entire code is in fast-import.c. The input stream it consumes
comes in on STDIN and is documented in a large comment at the top
of the file.
All that's needed is to get data from SVN in a way that it can be
fed into git-fastimport.
--
Shawn.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 2:53 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Linus Torvalds, Junio C Hamano, Sasha Khapyorsky,
Git Mailing List
In-Reply-To: <20070104024523.GD18206@spearce.org>
On 1/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Chris Lee <chris133@gmail.com> wrote:
> > On 1/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > >I should also point out that my git-fastimport hack that we used
> > >on the huge Mozilla import may be helpful here. Its _very_ fast
> > >as it goes right to a pack file, but there's no SVN frontend for
> > >it at this time.
> >
> > I would be *really* interested in playing with that. Where do I get it?
>
> Its a fork of git.git on repo.or.cz; the gitweb can be seen here:
>
> http://repo.or.cz/w/git/fastimport.git
>
> the clone url is:
>
> git://repo.or.cz/git/fastimport.git
> http://repo.or.cz/r/git/fastimport.git
>
> The entire code is in fast-import.c. The input stream it consumes
> comes in on STDIN and is documented in a large comment at the top
> of the file.
Neat. How do I do that?
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Shawn O. Pearce @ 2007-01-04 2:57 UTC (permalink / raw)
To: Chris Lee; +Cc: Git Mailing List
In-Reply-To: <204011cb0701031853xd226683g85f376c206aacf3e@mail.gmail.com>
[cc: list modified to remove folks who probably aren't immediately
interested in git-fastimport]
Chris Lee <chris133@gmail.com> wrote:
> On 1/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >the clone url is:
> >
> > git://repo.or.cz/git/fastimport.git
> > http://repo.or.cz/r/git/fastimport.git
> >
> >The entire code is in fast-import.c. The input stream it consumes
> >comes in on STDIN and is documented in a large comment at the top
> >of the file.
>
> Neat. How do I do that?
I'm not sure I understand the question...
--
Shawn.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 2:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20070104025659.GE18206@spearce.org>
Uh... somehow, it lost this part:
> All that's needed is to get data from SVN in a way that it can be
> fed into git-fastimport.
That's what I meant - I assume that someone already has the
svn-repo-to-gfi piece working? Where's that available from?
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Shawn O. Pearce @ 2007-01-04 3:05 UTC (permalink / raw)
To: Chris Lee; +Cc: Git Mailing List
In-Reply-To: <204011cb0701031858x231df34as424b7f0c0ae4ab8b@mail.gmail.com>
Chris Lee <chris133@gmail.com> wrote:
> Uh... somehow, it lost this part:
>
> >All that's needed is to get data from SVN in a way that it can be
> >fed into git-fastimport.
>
> That's what I meant - I assume that someone already has the
> svn-repo-to-gfi piece working? Where's that available from?
No. That hasn't been written.
In theory someone could take the SVN dump library (its a chunk of
C code which parses SVN dump files) and write a tool which translates
it into git-fastimport.
One could also use the SVN client library to suck data from SVN
and pump it into git-fastimport.
Jon Smirl attempted to create a CVS-->git-fastimport program in
Python by starting with the cvs2svn codebase, but that doesn't
do anything about importing *from* SVN. Jon was able to import
the entire Mozilla CVS repository (250k commits, about 3 GiB
input) in 2 hours using his hacked up cvs2svn and git-fastimport.
The resulting pack was ~900 MiB. He recompressed that using
`git repack -a -d --window=50 --depth=1000` (which is insane) in
about an hour.
--
Shawn.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 3:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <204011cb0701031858x231df34as424b7f0c0ae4ab8b@mail.gmail.com>
On 1/3/07, Chris Lee <chris133@gmail.com> wrote:
> Uh... somehow, it lost this part:
>
> > All that's needed is to get data from SVN in a way that it can be
> > fed into git-fastimport.
>
> That's what I meant - I assume that someone already has the
> svn-repo-to-gfi piece working? Where's that available from?
Right, and I'm an idiot! Awesome.
I obviously didn't comprehend the part where you wrote:
> I should also point out that my git-fastimport hack that we used
> on the huge Mozilla import may be helpful here. Its _very_ fast
> as it goes right to a pack file, but there's no SVN frontend for
> it at this time.
Anyway. Thanks for the pointers, I'll see if I can't hack something up.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Eric Wong @ 2007-01-04 3:13 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Chris Lee, Linus Torvalds, Junio C Hamano, Shawn Pearce,
Sasha Khapyorsky, Git Mailing List
In-Reply-To: <86ps9vbjlp.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>
> Eric> Part of it is Perl, which (as far as I know) never frees allocated
> Eric> memory back to the OS (although Perl can reuse the allocated memory for
> Eric> other things).
>
> It does on Linux, of all things. That's because Linux has a smarter
> malloc/free that uses mmap(2) for the large chunks. On Linux, Perl memory
> size can apparently grow and shrink nicely. The "old school" advice about
> Perl comes from sbrk(2)-driven malloc/free.
>
> Try:
>
> $x[1e6] = "0";
> sleep 10; # do a ps here
> @x = ();
> sleep 30; # do a ps here
>
> and watch the process on Linux. If I'm right, this should show a large
> process, then a smaller one.
Nope, not happening to me. I'm using Perl 5.8.8-7 and glibc 2.3.6.ds1-8
on a Debian Etch machine. The kernel is a vanilla 2.6.18.1 from
kernel.org.
strace shows an mmap2 call, but no corresponding mumap. I've added a
sleep loop to the end of the above program and had it print
something every 10 seconds; but so far, there's still no munmap.
while (1) {
print "hi\n" if ((time % 10) == 0);
sleep 1;
}
Trying to allocate a bigger chunk (1e7) doesn't show anything different,
either. I've also conducted similar experiments with Ruby in the past
and noticed the same things...
--
Eric Wong
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: linux @ 2007-01-04 5:28 UTC (permalink / raw)
To: junkio, linux; +Cc: git, tytso
In-Reply-To: <7v1wmcox5w.fsf@assigned-by-dhcp.cox.net>
> Seconded. Can I have the latest round?
Uh... can it wait a day or two? I'm leaving for a camping trip
tomorrow and won't have much keyboard access...
Sorry about that.
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Junio C Hamano @ 2007-01-04 6:11 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20070104052829.15254.qmail@science.horizon.com>
linux@horizon.com writes:
>> Seconded. Can I have the latest round?
>
> Uh... can it wait a day or two? I'm leaving for a camping trip
> tomorrow and won't have much keyboard access...
No worries. Have fun.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Junio C Hamano @ 2007-01-04 6:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Lee, Shawn Pearce, Sasha Khapyorsky, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0701031737300.4989@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 3 Jan 2007, Chris Lee wrote:
>>
>> So I'm using git 1.4.1, and I have been experimenting with importing
>> the KDE sources from Subversion using git-svnimport.
>
> As one single _huge_ import? All the sub-projects together? I have to say,
> that sounds pretty horrid.
Thanks -- you said everything I should have said on this issue
while I was in bed ;-).
> Junio - I suspect "pack-check.c" really shouldn't try to do it as one
> single humungous "SHA1_Update()" call. It showed one bug on PPC, I
> wouldn't be surprised if it's implicated now on some other architecture.
If Chris still has that huge .pack & .idx pair, it would be a
very good guinea pig to try a few things on, assuming that this
problem is that the pack-check.c feeds a huge blob to SHA-1
function with a single call.
(1) Apply the attached patch on top of "master" (the patch
should apply to 1.4.1 almost cleanly as well, except that
we have hashcmp(a,b) instead of memcmp(a,b,20) since then),
and see what it says about the packfile. If your suspicion
is correct, it should complain about your SHA-1
implementation.
(2) Try tip of "next" to see if its verify-pack passes the
check. Again, if your suspicion is correct, it should, since it
uses Shawn's sliding mmap() stuff that will not feed the
whole pack in one go.
(3) I suspect that the tip of "master" should work except
verify-pack. It may be interesting to see how well the tip
of "master" and "next" performs on the resulting huge pack
(say, "time git log -p HEAD >/dev/null"). I am hoping this
would be another datapoint to judge the runtime penalty of
Shawn's sliding mmap() in "next" -- I suspect the penalty
is either negligible or even negative.
diff --git a/pack-check.c b/pack-check.c
index c0caaee..738a0c5 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -29,6 +29,28 @@ static int verify_packfile(struct packed_git *p)
pack_base = p->pack_base;
SHA1_Update(&ctx, pack_base, pack_size - 20);
SHA1_Final(sha1, &ctx);
+
+ if (1) {
+ SHA_CTX another;
+ unsigned char *data = p->pack_base;
+ unsigned long size = pack_size - 20;
+ const unsigned long batchsize = (1u << 20);
+ unsigned char another_sha1[20];
+
+ SHA1_Init(&another);
+ while (size) {
+ unsigned long batch = size;
+ if (batchsize < batch)
+ batch = batchsize;
+ SHA1_Update(&another, data, batch);
+ size -= batch;
+ data += batch;
+ }
+ SHA1_Final(another_sha1, &another);
+ if (hashcmp(sha1, another_sha1))
+ die("Your SHA-1 implementation cannot hash %lu bytes correctly at once", pack_size - 20);
+ }
+
if (hashcmp(sha1, (unsigned char *)pack_base + pack_size - 20))
return error("Packfile %s SHA1 mismatch with itself",
p->pack_name);
^ permalink raw reply related
* Re: git completely non-operational w/ curl 7.16.0
From: Junio C Hamano @ 2007-01-04 6:45 UTC (permalink / raw)
To: felix-git; +Cc: git
In-Reply-To: <20070104023150.GA31151@codeblau.de>
felix-git@fefe.de writes:
> I'm using git 1.4.4.3 on x86_64-linux with curl 7.16.0, glibc 2.5, gcc
> 4.1.1 and binutils 2.17. All of these are as far as I know the current
> release versions.
This may be related to a bug in cURL 7.16.0, which is reported
to be fixed in their current CVS version:
http://curl.haxx.se/mail/archive-2006-12/0085.html
In the meantime, we have a workaround for this particular
problem the above URL mentions since last week.
Please try "master" (or anything later than v1.5.0-rc0) to see
if it still breaks for you.
The fix also should apply cleanly on top of 1.4.4.3.
-- >8 --
[PATCH] Work around http-fetch built with cURL 7.16.0
It appears that curl_easy_duphandle() from libcurl 7.16.0
returns a curl session handle which fails GOOD_MULTI_HANDLE()
check in curl_multi_add_handle(). This causes fetch_ref() to
fail because start_active_slot() cannot start the request.
For now, check for 7.16.0 to work this issue around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff --git a/http.h b/http.h
index 6e12e41..324fcf4 100644
--- a/http.h
+++ b/http.h
@@ -18,7 +18,7 @@
#define curl_global_init(a) do { /* nothing */ } while(0)
#endif
-#if LIBCURL_VERSION_NUM < 0x070c04
+#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)
#define NO_CURL_EASY_DUPHANDLE
#endif
^ permalink raw reply related
* [PATCH] pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
From: Junio C Hamano @ 2007-01-04 7:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Lee, Shawn Pearce, Sasha Khapyorsky, Git Mailing List
In-Reply-To: <7v1wmbnw9x.fsf@assigned-by-dhcp.cox.net>
Running the SHA1_Update() on the whole packfile in a single call
revealed an overflow problem we had in the SHA-1 implementation
on POWER architecture some time ago, which was fixed with commit
b47f509b (June 19, 2006). Other SHA-1 implementations may have
a similar problem.
The sliding mmap() series already makes chunked calls to
SHA1_Update(), so this patch itself will become moot when it
graduates to "master", but in the meantime, run the hash
function in smaller chunks to prevent possible future problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Chris, if you have a chance could you try this on the huge
pack you had trouble with?
Also whose SHA-1 implementation are you using, if this indeed
is the problem, I wonder?
pack-check.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/pack-check.c b/pack-check.c
index c0caaee..8e123b7 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,16 +1,18 @@
#include "cache.h"
#include "pack.h"
+#define BATCH (1u<<20)
+
static int verify_packfile(struct packed_git *p)
{
unsigned long index_size = p->index_size;
void *index_base = p->index_base;
SHA_CTX ctx;
unsigned char sha1[20];
- unsigned long pack_size = p->pack_size;
- void *pack_base;
struct pack_header *hdr;
int nr_objects, err, i;
+ unsigned char *packdata;
+ unsigned long datasize;
/* Header consistency check */
hdr = p->pack_base;
@@ -25,11 +27,19 @@ static int verify_packfile(struct packed_git *p)
"while idx size expects %d", nr_objects,
num_packed_objects(p));
+ /* Check integrity of pack data with its SHA-1 checksum */
SHA1_Init(&ctx);
- pack_base = p->pack_base;
- SHA1_Update(&ctx, pack_base, pack_size - 20);
+ packdata = p->pack_base;
+ datasize = p->pack_size - 20;
+ while (datasize) {
+ unsigned long batch = (datasize < BATCH) ? datasize : BATCH;
+ SHA1_Update(&ctx, packdata, batch);
+ datasize -= batch;
+ packdata += batch;
+ }
SHA1_Final(sha1, &ctx);
- if (hashcmp(sha1, (unsigned char *)pack_base + pack_size - 20))
+
+ if (hashcmp(sha1, (unsigned char *)(p->pack_base) + p->pack_size - 20))
return error("Packfile %s SHA1 mismatch with itself",
p->pack_name);
if (hashcmp(sha1, (unsigned char *)index_base + index_size - 40))
^ permalink raw reply related
* [0/2 PATCH] FastCGI and nginx support for gitweb
From: Eric Wong @ 2007-01-04 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I was looking at nginx for another project and got sidetracked
into writing instaweb support for it; so I ended up writing a
simple FCGI wrapper for gitweb as well.
---
.gitignore | 1 +
Makefile | 11 ++++++-
git-instaweb.sh | 72 ++++++++++++++++++++++++++++++++++++++++++++++-
gitweb/gitweb-fcgi.perl | 51 +++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 1 +
5 files changed, 134 insertions(+), 2 deletions(-)
--
Eric Wong
^ 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