* git-fast-export hg mutt (24M vs 184M)
From: Thomas Glanzmann @ 2007-05-03 18:56 UTC (permalink / raw)
To: GIT
Hello,
I just tried to vendor track / import the mutt hg repository into git.
git-fast-export-hg is quiet amazing but the resulting git repository
blows up in size and I have not the slightes clue why.
git clone git://repo.or.cz/fast-export.git
hg clone http://dev.mutt.org/hg/mutt
Could someone have a look at this? I used Debian Etch with a git version
I build myself using an ugly script. I had to upgrade mecurial as well
because the version didn't had the cmdlog.py. I used the unstable debian
package for that.
(thinkpad) [~/work/mutt] git-init-db
Initialized empty Git repository in .git/
(thinkpad) [~/work/mutt] ~/work/fast-export/hg-fast-export.sh -r /tmp/mutt
git version 1.5.2.rc0.56.g6169a
Thomas
^ permalink raw reply
* Re: git-fast-export hg mutt (24M vs 184M)
From: Thomas Glanzmann @ 2007-05-03 19:17 UTC (permalink / raw)
To: GIT
In-Reply-To: <20070503185623.GA11817@cip.informatik.uni-erlangen.de>
Hello,
git-repack -a -d -f got it down to 19M. I missed the -f parameter
before. Sorry for the noise.
Thomas
^ permalink raw reply
* [PATCH StGIT] Fix deleting series trash directory
From: Roland Dreier @ 2007-05-03 18:29 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
When deleting a series, the loop that iterates through the files in
__trash_dir needs to add __trash_dir to the filename that it passes to
os.remove().
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
diff --git a/stgit/stack.py b/stgit/stack.py
index b0a01dd..4e5ddb3 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -665,7 +665,7 @@ class Series(StgitObject):
# remove the trash directory
for fname in os.listdir(self.__trash_dir):
- os.remove(fname)
+ os.remove(os.path.join(self.__trash_dir, fname))
os.rmdir(self.__trash_dir)
# FIXME: find a way to get rid of those manual removals
^ permalink raw reply related
* [PATCH] Document 'opendiff' value in config.txt and git-mergetool.txt
From: Arjen Laarhoven @ 2007-05-03 18:29 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
Documentation/config.txt | 2 +-
Documentation/git-mergetool.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c257cdf..24f9655 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -520,7 +520,7 @@ merge.summary::
merge.tool::
Controls which merge resolution program is used by
gitlink:git-mergetool[l]. Valid values are: "kdiff3", "tkdiff",
- "meld", "xxdiff", "emerge", "vimdiff"
+ "meld", "xxdiff", "emerge", "vimdiff", and "opendiff"
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 34288fe..add01e8 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,7 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, and vimdiff.
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
--
1.5.2.rc1.3.g7a150
^ permalink raw reply related
* Re: how to filter a pull
From: Junio C Hamano @ 2007-05-03 18:21 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, marc.zonzon
In-Reply-To: <20070503150752.GB6500@xp.machine.xx>
Peter Baumann <waste.manager@gmx.de> writes:
> On Thu, May 03, 2007 at 03:17:05PM +0200, marc.zonzon@gmail.com wrote:
>> I have projects that draw some parts from two or three other
>> projects. But it is usually some small part, that are included, and
>> patched in my project. I want to follow the development of these fellow
>> projects.
>> ...
> Perhaps the newly added merge strategy subtree [1] could work. Or the
> just added subproject support, but this is very new and only the lowlevel machinery
> is implemented right now.
I do not think subtree merge would work with this situation, as
it is only for cases that one side of the merge represents a
tree that is a subset of the tree of the other side of the
merge. marc.zonzon's case does not fit the pattern.
If I were doing this 6 months from now, I would probably use
subproject to host the whole tree of other projects somewhere,
adjust the build procedure of the primary project to borrow the whole of these other
projects not just subtree -- or have appropriate symlinks in the
superproject that point into relevant subtrees in the
subprojects.
If I were doing this today, I would probably use separate
repositories, next to the primary project, to host the whole
tree of other projects, adjust the build procedure of the
primary project to borrow the whole of these other projects not
just subtree -- and/or have appropriate symlinks in the primary
project that point into relevant subtrees in the neighbouring
repositories that host these other projects.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Uwe Kleine-König @ 2007-05-03 18:00 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <loom.20070502T111026-882@post.gmane.org>
Hello,
Panagiotis Issaris wrote:
> There are some other things the FFmpeg maintainer mentions, namely:
> * He wants to be able to revert a commit in some way without "wiping" history.
> That is without committing a patch which reverses the broken commit, as this
> would pollute "git blame". The maintainer sees this as critical feature for
> switching to git as it apparently can be doing using Subversion:
> "in svn we can do this with svn cp from a specific
> revission git and mercurial lack proper copy support"
To add more context, Michael Niedermayer (=FFmpeg maintainer) wrote (in
[1]):
let me explain a little bit why this is critically needed
think of someone misstakely commiting the whole ffmpeg
reindented or mistakely commiting a old ffmpeg version over the
new or another total messup, these things do happen, and
especially if they cannot be corrected and at the time where
none of the developers is around
For me this sounds like: I don't want people with commit access doing
this, and if they do, I want to be able to revert it.
If FFmpeg used a development scheme similar to the linux kernel, there
should be no need for revert: The upstream maintainer only needs to pay
attention to the things he does directly (he probably does in any case)
and check the patches he applies and the trees he pulls. As git gives a
diffstat on pull and he reviews patches before applying the problem is
maybe gone?
Commit access is simply different in a distributed environment, see
http://thread.gmane.org/gmane.comp.version-control.git/45849/focus=45956
Best regards
Uwe
> [1]
> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/49673
--
Uwe Kleine-König
http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
^ permalink raw reply
* Re: suggested feature: completely expunge a file (or just a delta) a la rebase
From: Mike Coleman @ 2007-05-03 16:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0704261716140.12006@racer.site>
I have no idea why bike sheds should be painted red (though this does
sound very vaguely familiar). I did get a chance to try out
cg-admin-rewritehist last night, and it worked like a charm. Even got
rid of my graft point (my project has previously lived in RCS, CVS,
and Subversion).
Anyway, it'd definitely be useful, I think, especially as a means to
unroll newby mistakes such as mine.
Mike
On 4/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 26 Apr 2007, Mike Coleman wrote:
>
> > On 4/26/07, Junio C Hamano <junkio@cox.net> wrote:
> > > There have been talks about polishing cg-rewritehist into a
> > > shape suitable for inclusion in core git.git, now Cogito is not
> > > actively developed anymore.
> >
> > Ah, that looks like it'd fit the bill. I may see if it'll still work
> > for my simple case. Thanks for the pointer.
> >
> > > I think the first thing to fix is its name "rewritehist", which
> > > may technically be correct, feels a bit too ugly ;-)
> >
> > Naming is very important.
>
> Maybe git-rewrite-commits?
>
> > I seem to recall hearing (from PE) that one of the early Unix guys was
> > later asked if there was anything they'd change in hindsight. Their
> > response: they'd spell "creat" with an 'e'.
>
> In related news: there is really no question that bike sheds should be
> painted red. Really.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: [git-svn PATCH] Add --no-rebase option to git-svn dcommit
From: Seth Falcon @ 2007-05-03 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <87647aqu6i.fsf@morpheus.local>
David Kågedal <davidk@lysator.liu.se> writes:
> Karl Hasselström <kha@treskal.com> writes:
>
>> git-svn dcommit exports commits to Subversion, then imports them back
>> to git again, and last but not least rebases or resets HEAD to the
>> last of the new commits. I guess this rebasing is convenient when
>> using just git, but when the commits to be exported are managed by
>> StGIT, it's really annoying. So add an option to disable this
>> behavior. And document it, too!
>>
>> Signed-off-by: Karl Hasselström <kha@treskal.com>
>> ---
>>
>> Arguably, the switch should be --rebase instead, and default to not
>> rebase. But that would change the existing behavior, and possibly make
>> dcommit less convenient to use for at least the person who implemented
>> the existing behavior. Opinions?
>
> I don't agree. The rebase behaviour makes perfect sense in the normal
> case, and I've been using it without problems. The special case is
> when you start using stgit, so that's when you need to tell dcommit to
> do something out of the ordinary.
I'm happy with git-svn dcommit's current behavior. Since it is
git-svn and not git-stGIT, I'm not in favor of changing a default to
make a stGIT use case more convenient.
+ seth
^ permalink raw reply
* Re: [tools-dev] Re: Git benchmarks at OpenOffice.org wiki
From: Johannes Sixt @ 2007-05-03 15:14 UTC (permalink / raw)
To: git; +Cc: dev
In-Reply-To: <200705031351.40548.kendy@suse.cz>
Jan Holesovsky wrote:
> Last question: what is the status of the Win32 support? I got a full clone
> using the Cygwin git 1.5.0 [it took 6hrs 20min on a Xen virtual machine; I
> have to try it with real hardware], MinGW version did not work for me too
> well :-(
I'd really like to hear what you exactly mean by "MinGW version did not
work too well". I use it in production. (But then, I'm the one who
publishes the MinGW port ;)
-- Hannes
^ permalink raw reply
* Re: how to filter a pull
From: Peter Baumann @ 2007-05-03 15:07 UTC (permalink / raw)
To: marc.zonzon; +Cc: git
In-Reply-To: <20070503131704.GA7036@kernoel.kernoel.fr>
On Thu, May 03, 2007 at 03:17:05PM +0200, marc.zonzon@gmail.com wrote:
> I'm a git beginner (and an old user of cvs, and more recently of
> subversion, and occasionally of arch)
>
> I'm very pleased with the decentralized character of git and the ease
> to manage branches. But I have a usual problem that I don't know how
> to solve properly in git.
>
> I have projects that draw some parts from two or three other
> projects. But it is usually some small part, that are included, and
> patched in my project. I want to follow the development of these fellow
> projects.
>
> My problem is that I can of course get a branch to host a copy of the
> project (if the are under git I can clone and pull, if not I use the
> native scm to import and commit in the branch). But now I cannot merge
> in my development branch as I include only a small part.
>
> I found no way to register that I copy these part. The only one I can think of,
> is to have a script to extract a sub branch with only the appropriate
> part and then pull from it (or push to my project).
> i.e. I pull from the project (if git) or update in cvs, or ..., then I
> filter to extract the appropiate part, then push to my development branch.
>
> But I suppose there are a lot of cleaner way to do it. And moreover
> I'm quite sure that developers have met the same problem, and have solved it.
>
> Sorry to ask such a stupid question but
> (1) git naming itself stupid content tracker encourage dumb people
> like me to ask stupid questions .
> (2) I tried to RTFM, but could not find the appropriate page.
>
> Thank you for any hint.
Perhaps the newly added merge strategy subtree [1] could work. Or the
just added subproject support, but this is very new and only the lowlevel machinery
is implemented right now.
-Peter
[1]: http://git.kernel.org/?p=git/git.git;a=commit;h=68faf68938ee943fc251c702f2027e4dfda354db
^ permalink raw reply
* Re: Problem with case-insensitive file cleanup
From: Jim Meyering @ 2007-05-03 13:54 UTC (permalink / raw)
To: Eric Blake; +Cc: git, bug-gnulib
In-Reply-To: <4639DA65.3030401@byu.net>
Eric Blake <ebb9@byu.net> wrote:
> Right now, the gnulib repository is mastered in CVS but mirrored by git (I
> am still awaiting the day that Jim decides that his hooks are adequate
> enough that git can be the master and CVS provided by git-cvsserver).
My plan, once we make the switch, is to set things up so that CVS
die-hards can use git-cvsserver for read-only gnulib operations.
BTW, just yesterday there was a bug fix in git relating to git-cvsserver:
cvsserver: Handle re-added files correctly
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=a7da9adb1ff
> Earlier this week, I reported a problem when two case-insensitive files
> were created, which is a no-no for checkouts on Mac HFS+ or Windows-based
> platforms [1]. The problem was quickly corrected in CVS (note that
> _Exit.texi now lives in the attic [2]). But somehow the git repository
> still thinks that _Exit.texi belongs to the current tree [3], which leads
> to this confusing state on a case-insensitive clone:
I've just removed that file manually and pushed the result.
I suppose that happened because something went wrong with the
automated git-cvsimport run.
The current procedure is to rsync the CVS repository,
use that via git-cvsimport into an existing .git repository,
and then to push the result to savannah.
Obviously, before we do the final CVS-to-GIT switch, I'll rerun
git-cvsimport from scratch, rather relying on the incrementally-built-up one.
^ permalink raw reply
* Re: Problem with case-insensitive file cleanup
From: Alex Riesen @ 2007-05-03 13:32 UTC (permalink / raw)
To: Eric Blake; +Cc: git, bug-gnulib
In-Reply-To: <4639DA65.3030401@byu.net>
On 5/3/07, Eric Blake <ebb9@byu.net> wrote:
> Right now, the gnulib repository is mastered in CVS but mirrored by git (I
> am still awaiting the day that Jim decides that his hooks are adequate
> enough that git can be the master and CVS provided by git-cvsserver).
> Earlier this week, I reported a problem when two case-insensitive files
> were created, which is a no-no for checkouts on Mac HFS+ or Windows-based
> platforms [1]. The problem was quickly corrected in CVS (note that
> _Exit.texi now lives in the attic [2]). But somehow the git repository
> still thinks that _Exit.texi belongs to the current tree [3], ...
cvs-to-git conversion seem to be buggy in this respect
> What needs to happen to get rid of the _Exit.texi listing in the git
> repository, so that case insensitive file systems can clone the gnulib.git
> repository?
git update-index --force-remove _Exit.texi
git commit -m 'Really removed _Exit.texi'
^ permalink raw reply
* how to filter a pull
From: marc.zonzon @ 2007-05-03 13:17 UTC (permalink / raw)
To: git
I'm a git beginner (and an old user of cvs, and more recently of
subversion, and occasionally of arch)
I'm very pleased with the decentralized character of git and the ease
to manage branches. But I have a usual problem that I don't know how
to solve properly in git.
I have projects that draw some parts from two or three other
projects. But it is usually some small part, that are included, and
patched in my project. I want to follow the development of these fellow
projects.
My problem is that I can of course get a branch to host a copy of the
project (if the are under git I can clone and pull, if not I use the
native scm to import and commit in the branch). But now I cannot merge
in my development branch as I include only a small part.
I found no way to register that I copy these part. The only one I can think of,
is to have a script to extract a sub branch with only the appropriate
part and then pull from it (or push to my project).
i.e. I pull from the project (if git) or update in cvs, or ..., then I
filter to extract the appropiate part, then push to my development branch.
But I suppose there are a lot of cleaner way to do it. And moreover
I'm quite sure that developers have met the same problem, and have solved it.
Sorry to ask such a stupid question but
(1) git naming itself stupid content tracker encourage dumb people
like me to ask stupid questions .
(2) I tried to RTFM, but could not find the appropriate page.
Thank you for any hint.
^ permalink raw reply
* Re: [tools-dev] Re: Git benchmarks at OpenOffice.org wiki
From: Alex Riesen @ 2007-05-03 12:54 UTC (permalink / raw)
To: Jan Holesovsky; +Cc: dev, Jakub Narebski, git
In-Reply-To: <200705031351.40548.kendy@suse.cz>
On 5/3/07, Jan Holesovsky <kendy@suse.cz> wrote:
> Last question: what is the status of the Win32 support?
It kind of works. Performance is horrible, but still better
than almost everything comparable (and there isn't anything
comparable). You have to be very careful not to push it
(them, actually: cygwin and windows) too hard: it is quick
to fall over taking down the whole machine with it (yes,
avoid Ctrl-C at all costs).
The repos have always been recoverable for me, though.
> I got a full clone using the Cygwin git 1.5.0 [it took 6hrs 20min
> on a Xen virtual machine; I have to try it with real hardware],
> MinGW version did not work for me too well :-(
> Are there any other options?
Avoid Win32 if possible, work somewhere in a sane environment,
using windows for testing, if you have to.
> Is http://git.or.cz/gitwiki/WindowsInstall up-to-date?
Yes.
^ permalink raw reply
* Problem with case-insensitive file cleanup
From: Eric Blake @ 2007-05-03 12:49 UTC (permalink / raw)
To: git; +Cc: bug-gnulib
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right now, the gnulib repository is mastered in CVS but mirrored by git (I
am still awaiting the day that Jim decides that his hooks are adequate
enough that git can be the master and CVS provided by git-cvsserver).
Earlier this week, I reported a problem when two case-insensitive files
were created, which is a no-no for checkouts on Mac HFS+ or Windows-based
platforms [1]. The problem was quickly corrected in CVS (note that
_Exit.texi now lives in the attic [2]). But somehow the git repository
still thinks that _Exit.texi belongs to the current tree [3], which leads
to this confusing state on a case-insensitive clone:
$ git pull
Already up-to-date.
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: doc/functions/_Exit.texi
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git reset --hard HEAD
HEAD is now at 7464768... Merge branch 'master' of git://git.sv.gnu.org/gnulib
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: doc/functions/_exit.texi
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git reset --hard HEAD
HEAD is now at 7464768... Merge branch 'master' of git://git.sv.gnu.org/gnulib
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: doc/functions/_Exit.texi
#
no changes added to commit (use "git add" and/or "git commit -a")
What needs to happen to get rid of the _Exit.texi listing in the git
repository, so that case insensitive file systems can clone the gnulib.git
repository?
[1]http://lists.gnu.org/archive/html/bug-gnulib/2007-05/msg00012.html
[2]http://cvs.savannah.gnu.org/viewcvs/gnulib/doc/functions/Attic/_Exit.texi?rev=1.3&root=gnulib&view=log
[3]http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/functions;hb=a71ea03e4262db77dd90eaf35bad5fee6f79d15e
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGOdpl84KuGfSFAYARAhyEAJ9RFH9anyBa69uksVmG+0XetFJlvgCeNBsf
t1ppuGgwxq/kGr0G6qZGV6g=
=vS7d
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Segmentation fault in git-svn
From: Peter Baumann @ 2007-05-03 12:35 UTC (permalink / raw)
To: Eric Wong; +Cc: Steven Grimm, git
In-Reply-To: <4623F613.5010108@midwinter.com>
On Mon, Apr 16, 2007 at 03:17:55PM -0700, Steven Grimm wrote:
> I expect this is really a libsvn bug, but git-svn triggers it, so I'm hoping
> someone else has run into and solved it, or at least that someone can
> reproduce it.
>
> If I try to clone the "memcached" public repository with the command line
>
> git-svn clone --branches=branches --trunk=trunk
> http://code.sixapart.com/svn/memcached
>
> it cranks along fine until revision 299, then dies with SIGSEGV. If I run it
> again, it appears to pick up where it left off, then dies again at revision
> 399, then again at revision 499. (There are fewer than 600 revisions in that
> repo so it's anyone's guess if it'd die at 599 given the chance.)
>
> This happens on both a Linux box (amd64, FC4, svn version 1.4.3) and my Mac
> (Intel OS 10.4, svn version 1.2.3 from Fink), so at the very least it's not
> platform-specific. It also happens periodically on the private svn
> repository at my company, though not as predictably. On my Mac, I'm using
> the very latest git code from "master".
>
I'm getting segfaults in git-svn, too.
This command segfaults reproducably in r55 while running
git svn clone svn://svn.berlios.de/vermont vermont \
-T trunk -b branches -t tags
I recompiled the debian subversion 1.4.3dfsg1-1 with debug support, to get a better
idea what went wrong.
Relevant output from running this beast under valgrind:
(full valgrind output available at [1])
[...]
r54 = f80e8d0ad785cae5a4abfb1fdd04b31167553ab0 (trunk)
D collector/src/testCollector.h
M collector/src/rcvIpfix.h
M collector/src/rcvMessage.c
M collector/src/common.c
M collector/src/rcvIpfix.c
M collector/src/common.h
r55 = 3fddc1de138e9457385ff43111bcaf6f82884525 (trunk)
==10403==
==10403== Invalid read of size 1
==10403== at 0x59F90A6: readbuf_getchar (marshal.c:285)
==10403== by 0x59F90E6: readbuf_getchar_skip_whitespace (marshal.c:294)
==10403== by 0x59FA0F3: svn_ra_svn_read_item (marshal.c:621)
==10403== by 0x59FA628: svn_ra_svn_read_tuple (marshal.c:741)
==10403== by 0x59FA906: svn_ra_svn_read_cmd_response (marshal.c:799)
==10403== by 0x59ED81D: handle_auth_request (client.c:346)
==10403== by 0x59F02B1: ra_svn_check_path (client.c:1284)
==10403== by 0x59B7FD7: svn_ra_check_path (ra_loader.c:564)
==10403== by 0x599DC93: _wrap_svn_ra_check_path (svn_ra.c:6019)
==10403== by 0x80BDAD0: Perl_pp_entersub (in /usr/bin/perl)
==10403== by 0x80BC3A8: Perl_runops_standard (in /usr/bin/perl)
==10403== by 0x8063A1A: perl_run (in /usr/bin/perl)
==10403== Address 0x6F6C6720 is not stack'd, malloc'd or (recently) free'd
==10403==
==10403== Process terminating with default action of signal 11 (SIGSEGV)
==10403== Access not within mapped region at address 0x6F6C6720
==10403== at 0x59F90A6: readbuf_getchar (marshal.c:285)
==10403== by 0x59F90E6: readbuf_getchar_skip_whitespace (marshal.c:294)
==10403== by 0x59FA0F3: svn_ra_svn_read_item (marshal.c:621)
==10403== by 0x59FA628: svn_ra_svn_read_tuple (marshal.c:741)
==10403== by 0x59FA906: svn_ra_svn_read_cmd_response (marshal.c:799)
==10403== by 0x59ED81D: handle_auth_request (client.c:346)
==10403== by 0x59F02B1: ra_svn_check_path (client.c:1284)
==10403== by 0x59B7FD7: svn_ra_check_path (ra_loader.c:564)
==10403== by 0x599DC93: _wrap_svn_ra_check_path (svn_ra.c:6019)
==10403== by 0x80BDAD0: Perl_pp_entersub (in /usr/bin/perl)
==10403== by 0x80BC3A8: Perl_runops_standard (in /usr/bin/perl)
==10403== by 0x8063A1A: perl_run (in /usr/bin/perl)
==10403==
==10403== ERROR SUMMARY: 199 errors from 26 contexts (suppressed: 19 from 1)
==10403== malloc/free: in use at exit: 7,028,898 bytes in 129,440 blocks.
==10403== malloc/free: 325,184 allocs, 195,744 frees, 21,303,514 bytes allocated.
==10403== For counts of detected errors, rerun with: -v
==10403== searching for pointers to 129,440 not-freed blocks.
==10403== checked 7,214,984 bytes.
==10403==
==10403== LEAK SUMMARY:
==10403== definitely lost: 4,657 bytes in 118 blocks.
==10403== possibly lost: 216 bytes in 13 blocks.
==10403== still reachable: 7,024,025 bytes in 129,309 blocks.
==10403== suppressed: 0 bytes in 0 blocks.
==10403== Use --leak-check=full to see details of leaked memory.
===========================================================================
subversion/libsvn_ra_svn/marshal.c:
[...]
280 static svn_error_t *readbuf_getchar(svn_ra_svn_conn_t *conn,
apr_pool_t *pool,
281 char *result)
282 {
283 if (conn->read_ptr == conn->read_end)
284 SVN_ERR(readbuf_fill(conn, pool));
285 *result = *conn->read_ptr++; <-------- SEGFAULT happens here
286 return SVN_NO_ERROR;
287 }
===========================================================================
gdb backtrace:
r54 = f80e8d0ad785cae5a4abfb1fdd04b31167553ab0 (trunk)
D collector/src/testCollector.h
M collector/src/rcvIpfix.h
M collector/src/rcvMessage.c
M collector/src/common.c
M collector/src/rcvIpfix.c
M collector/src/common.h
r55 = 3fddc1de138e9457385ff43111bcaf6f82884525 (trunk)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210452288 (LWP 17426)]
0xb745f0a6 in readbuf_getchar (conn=0x877bf78, pool=0x88a6178,
result=0xbfea011f "\bL:F�L:F�X\001�\006F�x�w\bxa\212\bD\001�230��x�w\b�\212\b�F�\002")
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:285
285 *result = *conn->read_ptr++;
(gdb) bt
#0 0xb745f0a6 in readbuf_getchar (conn=0x877bf78, pool=0x88a6178,
result=0xbfea011f "\bL:F�L:F�X\001�\006F�x�w\bxa\212\bD\001�230��x�w\b�\212\b�F�\002")
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:285
#1 0xb745f0e7 in readbuf_getchar_skip_whitespace (conn=0x877bf78, pool=0x88a6178,
result=0xbfea011f "\bL:F�L:F�X\001�\006F�x�w\bxa\212\bD\001�230��x�w\b�\212\b�F�\002")
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:294
#2 0xb74600f4 in svn_ra_svn_read_item (conn=0x877bf78, pool=0x88a6178, item=0xbfea0144)
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:621
#3 0xb7460629 in svn_ra_svn_read_tuple (conn=0x877bf78, pool=0x88a6178, fmt=0xb7462607 "wl")
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:741
#4 0xb7460907 in svn_ra_svn_read_cmd_response (conn=0x877bf78, pool=0x88a6178, fmt=0xb7461372 "lc")
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/marshal.c:799
#5 0xb745381e in handle_auth_request (sess=0x877e1e8, pool=0x88a6178)
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/client.c:346
#6 0xb74562b2 in ra_svn_check_path (session=0x8778090, path=0x8899d48 "tags/collector-orig", rev=56, kind=0xbfea02c8, pool=0x88a6178)
at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra_svn/client.c:1284
#7 0xb7495fd8 in svn_ra_check_path (session=0x8778090, path=0x8899d48 "tags/collector-orig", revision=56, kind=0xbfea02c8,
pool=0x88a6178) at /tmp/buildd/subversion-1.4.3dfsg1/subversion/libsvn_ra/ra_loader.c:564
#8 0xb74c2c94 in _wrap_svn_ra_check_path (my_perl=0x814e008, cv=0x85e1a94) at svn_ra.c:6019
#9 0x080bdad1 in Perl_pp_entersub ()
#10 0x080bc3a9 in Perl_runops_standard ()
#11 0x08063a1b in perl_run ()
#12 0x0805ffd1 in main ()
(gdb)
I'm a little lost in debuging this any further. So if anyone could give
me some advice ... feel free to contact me by mail or in #git
(nickname siprbaum)
-Peter
My system is debian etch with backported subversion + patch in [2] and git from
debian unstable/experimental
ii git-core 1.5.1.3-1
ii git-svn 1.5.1.3-1
ii libsvn-perl 1.4.3dfsg1-1
ii libsvn1 1.4.3dfsg1-1
ii subversion 1.4.3dfsg1-1
[1]: http://wwwcip.informatik.uni-erlangen.de/~siprbaum/git-svn-segfault.txt
[2]: http://svn.haxx.se/dev/archive-2007-01/0936.shtml
^ permalink raw reply
* Re: [tools-dev] Re: Git benchmarks at OpenOffice.org wiki
From: Jan Holesovsky @ 2007-05-03 11:51 UTC (permalink / raw)
To: dev; +Cc: Jakub Narebski, git
In-Reply-To: <200705030130.44018.jnareb@gmail.com>
Hi Jakub,
On Thursday 03 May 2007 01:30, Jakub Narebski wrote:
> >> What might help here is splitting repository into current (e.g. from
> >> OOo 2.0) and historical part,
> >
> > No, I don't want this ;-)
>
> I forgot to add there is possible to graft historical repository to the
> current work repository, resulting in full history available. For example
> Linux kernel repository has backported from BK historical repository, and
> there is grafts file which connect those two repositories.
Yes, grafting sounds really very promising! - I did not know about it.
> >> and / or using shallow clone.
>
> git-clone(1):
>
> --depth <depth>::
> Create a 'shallow' clone with a history truncated to the
> specified number of revs. A shallow repository has
> number of limitations (you cannot clone or fetch from
> it, nor push from nor into it), but is adequate if you
> want to only look at near the tip of a large project
> with a long history, and would want to send in a fixes
> as patches.
>
> It is possible that those limitations will be lifted in the future
> (if possible), so there is alternate possibility to reduce needed
> disk space for git checkout. But certainly this is not for everybody.
It's probably too tight limitation for regular developers; for random hackers
contributing a patch or two it could be a choice, right.
> > We should better split the OOo sources; it's a process that already
> > started [UNO runtime environment vs. OOo without URE], and I proposed
> > some more changes already.
>
> In my opinion each submodule should be able to compile and test by
> itself. You can go X.Org route with splitting sources into modules...
Indeed, this is the case of URE - it is supposed to run by separately & be
used even by other projects than OOo.
> or you can make use of the new submodules support (currently plumbing
> level, i.e. low level commands), aka. gitlinks.
And this would be interesting for the translations, I guess...
> The submodules support makes it possible to split sources into
> independent modules (parts), which can be developed independently,
> and which you can download (clone, fetch) or not, while making it
> possible to bind it all together into one superproject.
>
> See (somewhat not up to date) http://git.or.cz/gitwiki/SubprojectSupport
> page on git wiki.
... but will have a better look; thanks for the pointer!
> Subversion doesn't have bisect, does it?
>From what I know, it does not.
Thank you and others for all the input!
Last question: what is the status of the Win32 support? I got a full clone
using the Cygwin git 1.5.0 [it took 6hrs 20min on a Xen virtual machine; I
have to try it with real hardware], MinGW version did not work for me too
well :-( Are there any other options? Is
http://git.or.cz/gitwiki/WindowsInstall up-to-date?
Regards,
Jan
^ permalink raw reply
* Re: git-svn and local only topic branch
From: Guilhem Bonnefille @ 2007-05-03 11:24 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <4638E127.4010303@midwinter.com>
On 5/2/07, Steven Grimm <koreth@midwinter.com> wrote:
> In his reply to my script, Junio correctly pointed out that all this
> fiddling really ought to be happening in git-svn itself; it ought to
> know that you've done a merge and should record that fact directly in
> the metadata for 4' rather than treating it as a single-parent commit.
> If you do the above a zillion times you'll end up with a huge grafts
> file which is not so clean. But as a stopgap measure, this does work
> adequately.
Yes, it's seems just fine. Thanks for the tips.
I'm not aware with the internal Git's features. As grafts seems to be
a quick hack, is it posible to imagine that, after git-svn rewrited 4
in 4', an other tool rewrites (completly) the commit to produce a 4"
with 2 parents?
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Martin Langhoff @ 2007-05-03 10:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, Florian Weimer, git
In-Reply-To: <200705031216.19817.robin.rosenberg.lists@dewire.com>
[resend - correcting a couple of typos and addressing git@vger
correctly - apologies]
On 5/3/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> The reason is simple. I have a lousy one gigabyte RAM only, while
> git wants 1.7GB virtual to do the diff-stat. and 800 MB resident. The swap is having a party,
That is true, unfortunately. git will fly if it can fit its working
set plus the kernel stat cache for your working tree in memory. And
the underlying assumption is that for large trees you'll have gobs of
RAM. If things don't fit, it does get rather slow...
But... just to put things in perspective, how long does it take to
*compile* that checkout on that same laptop. I remember reading
instructions to the tune of "don't even try to compile this with less
than 4GB RAM, a couple of CPUs and 12hs". Those were for the OSX build
IIRC.
Ah - it's moved to the general instructions: "Building OOo takes some
time (approx 10-12 hours on standard desktop PC) ":
http://wiki.services.openoffice.org/wiki/Building_OpenOffice.org#Starting_the_real_build
So I don't think anyone working on projects the size of the kernel or
OO.org is going to be happy with 1GB RAM.
cheers
m
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Robin Rosenberg @ 2007-05-03 10:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0705031131410.4015@racer.site>
torsdag 03 maj 2007 skrev Johannes Schindelin:
> Hi,
>
> On Thu, 3 May 2007, Florian Weimer wrote:
>
> > * Jakub Narebski:
> >
> > > What I'm really concerned about is branch switch and merging branches,
> > > when one of the branches is an old one (e.g. unxsplash branch), which
> > > takes 3min (!) according to the benchmark. 13-25sec for commit is also
> > > bit long, but BRANCH SWITCHING which takes 3 MINUTES!?
> >
> > IIRC, GIT accesses every file in the tree, not just the ones that need
> > updating. How many files were actually updated when you changed
> > branches in your experiment?
>
> No. Git does not access every file, but rather all stats. That is a huge
> difference. And it should not take _that_ long for ~64000 files. Granted,
> it will cause a substantial delay, but not in the range of minutes.
It's worse... On my laptop the switch took ~ten minutes, not three.
A diff --stat takes over six minutes!! For reference, dd:in the pack
file with my disk takes ~50 seconds.
The reason is simple. I have a lousy one gigabyte RAM only, while
git wants 1.7GB virtual to do the diff-stat. and 800 MB resident. The swap is having a party,
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 2 1861632 14108 428 126816 70 347 605 647 594 1041 11 2 74 13
0 2 1861204 12096 420 125724 3096 8 3096 24 625 1171 5 1 0 94
0 2 1860896 18972 404 115836 3524 292 3524 292 671 1474 7 4 0 89
0 2 1860820 18668 364 113736 3556 784 3556 784 669 1384 7 5 0 88
0 3 1860420 19692 300 109904 3008 180 3156 180 684 1325 8 5 0 87
0 3 1860184 18560 300 108596 3316 232 3396 232 643 1246 8 4 0 88
0 2 1859856 21808 292 103744 2108 32 2356 32 637 1319 9 1 0 90
-- robin
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Johannes Schindelin @ 2007-05-03 9:33 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87lkg61j99.fsf@mid.deneb.enyo.de>
Hi,
On Thu, 3 May 2007, Florian Weimer wrote:
> * Jakub Narebski:
>
> > What I'm really concerned about is branch switch and merging branches,
> > when one of the branches is an old one (e.g. unxsplash branch), which
> > takes 3min (!) according to the benchmark. 13-25sec for commit is also
> > bit long, but BRANCH SWITCHING which takes 3 MINUTES!?
>
> IIRC, GIT accesses every file in the tree, not just the ones that need
> updating. How many files were actually updated when you changed
> branches in your experiment?
No. Git does not access every file, but rather all stats. That is a huge
difference. And it should not take _that_ long for ~64000 files. Granted,
it will cause a substantial delay, but not in the range of minutes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make xstrndup common
From: Alex Riesen @ 2007-05-03 9:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0705022248040.28708@iabervon.org>
On 5/3/07, Daniel Barkalow <barkalow@iabervon.org> wrote:
> +static inline char *xstrndup(const char *str, int len)
> +{
> + char *ret;
> + int i;
> + for (i = 0; i < len && str[i]; i++)
> + ;
> + ret = xmalloc(i + 1);
> + strncpy(ret, str, i);
> + ret[i] = '\0';
> + return ret;
> +}
I'd suggest using platform-optimized memchr:
static inline char *xstrndup(const char *s, int len)
{
char *p = memchr(s, 0, len);
int n = p ? p - s: len;
p = xmalloc(n + 1);
memcpy(p, s, n);
p[n] = '\0';
return p;
}
^ permalink raw reply
* Re: [git-svn PATCH] Add --no-rebase option to git-svn dcommit
From: David Kågedal @ 2007-05-03 6:48 UTC (permalink / raw)
To: git
In-Reply-To: <20070503054749.20115.53805.stgit@yoghurt>
Karl Hasselström <kha@treskal.com> writes:
> git-svn dcommit exports commits to Subversion, then imports them back
> to git again, and last but not least rebases or resets HEAD to the
> last of the new commits. I guess this rebasing is convenient when
> using just git, but when the commits to be exported are managed by
> StGIT, it's really annoying. So add an option to disable this
> behavior. And document it, too!
>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> ---
>
> Arguably, the switch should be --rebase instead, and default to not
> rebase. But that would change the existing behavior, and possibly make
> dcommit less convenient to use for at least the person who implemented
> the existing behavior. Opinions?
I don't agree. The rebase behaviour makes perfect sense in the normal
case, and I've been using it without problems. The special case is
when you start using stgit, so that's when you need to tell dcommit to
do something out of the ordinary.
Other than that, I like your patch. But you knew that already :-)
--
David Kågedal
^ permalink raw reply
* Re: git-blame not tracking copies
From: Andy Parkins @ 2007-05-03 7:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v8xc64wsu.fsf@assigned-by-dhcp.cox.net>
On Thursday 2007 May 03, Junio C Hamano wrote:
> I am sick and not functioning well today, so will not be able to
I'm sorry to hear that. I hope you feel better soon.
> review what is happening with your example deeply, but here are
> some comments to get you started digging.
>
> There is a built-in sanity valve in git-blame that refuses to
> pass down the blame via -M/-C for really trivial hunks. Without
> such safety, all the empty lines in the latest revision would be
> attributed to a random empty line in a random file in the root
> commit ;-).
That sounds like an excellent feature. However - in the case of a full
file-to-file copy, surely that valve may be safely disabled for that one
step?
The copy is easily detectable because the hash is the same, so can't git-blame
just continue having flipped itself on to the original filename? I suppose
in essence a move is the same, the only difference between a move and a copy
is that in one case the copy is spatial in the other it is temporal.
Please excuse the fact that in the above I've completely minimised the fact
the job git-blame does is flippin' hard; I don't mean to imply that "any fule
could fix it" - because I can't :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Florian Weimer @ 2007-05-03 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <200705012346.14997.jnareb@gmail.com>
* Jakub Narebski:
> The problem is with 'Size of checkout': to start working in repository
> one needs 1.4G (sources) and 98M (third party) for CVS checkout (it is
> 1.5G for sources for Subversion checkout).
The text bases for Subversion really should take another 1.4 GiB.
As a result, Subversion should be closer to 3 GiB.
> What might help here is splitting repository into current (e.g. from
> OOo 2.0) and historical part, and / or using shallow clone.
You could also split along project boundaries, but this is probably
too political.
> What I'm really concerned about is branch switch and merging branches,
> when one of the branches is an old one (e.g. unxsplash branch), which
> takes 3min (!) according to the benchmark. 13-25sec for commit is also
> bit long, but BRANCH SWITCHING which takes 3 MINUTES!?
IIRC, GIT accesses every file in the tree, not just the ones that need
updating. How many files were actually updated when you changed
branches in your experiment?
^ 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