* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-16 22:10 UTC (permalink / raw)
To: Niklas Frykholm, git, Juergen Ruehle
In-Reply-To: <17554.48926.852000.679014@lapjr.intranet.kiel.bmiag.de>
On Fri, Jun 16, 2006 at 04:24:30PM +0200, Juergen Ruehle wrote:
>Niklas Frykholm writes:
> > I'm trying to use cygwin git (compiled from the 1.4.0 tarball) to create
> > repository on a windows network share, but I get an error message.
> >
> > $ cd //computer/git/project
> > $ git init-db
> > defaulting to local storage area
> > Could not rename the lock file?
>
>cygwin's rename seems to be capable of overwriting an existing target
>only on NTFS. The following hack is a workaround, but is probably not
>safe.
Actually, Cygwin's rename has a specific check to make sure that the
file is deleted. It tries very hard to do things the right way but if
your samba server doesn't return the correct error code then it is
possible that it could be confused.
cgf
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: David Kowis @ 2006-06-16 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j3gdc7t.fsf@assigned-by-dhcp.cox.net>
On Fri, 16 Jun 2006 16:55, Junio C Hamano wrote:
> David Kowis <dkowis@shlrm.org> writes:
>
>> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>> Author: David Kowis <dkowis@kain.org>
>> Date: Fri Jun 16 12:20:08 2006 -0500
>>
>> this is a multi
>>
>> line comment
>> with three lines
>>
>>
>> I'm using git 1.4.0. It added a blank line in there...
>
> Actually, this is an odd but intended behaviour ;-).
Why is this behaviour intended? Just because I'm curoius. :)
-- David Kowis - mobile
^ permalink raw reply
* parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-16 21:44 UTC (permalink / raw)
To: git
I'm getting thousands of messages about unnamed branches and even
'unnamed branch from master-UNNAMED-BRANCH'.
How do you get unnamed branches into CVS, are these check-in errors or
are people actually working on unnamed branches? Or is parsecvs not
finding all of the branch info?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* What's in cvsps.git
From: Yann Dirson @ 2006-06-16 21:44 UTC (permalink / raw)
To: GIT list; +Cc: cvsps, David D. Kilzer, Marcus Crafter
In-Reply-To: <20060611122746.GB7766@nowhere.earth>
I have now added all patches gathered from here, as well as those in
the current Debian package. Still have to dig other distros.
Note the log-length limit increment is being superceded by a dynamic
allocation patch.
Repo URL: http://ydirson.free.fr/soft/git/cvsps.git
==============================
* master has:
Alexander Litvinov:
Handle cvs repo with modules
Anand Kumria:
FreeBSD isn't evil - just misguided
David D. Kilzer:
cvsps: should ignore TRUNK branch if it exists in log
Dynamically allocate the log buffer to prevent warning messages
Linus Torvalds:
Increase log-length limit to 64kB
Improve handling of file collisions in the same patchset
Fix branch ancestor calculation
Pavel Roskin:
Use __linux__ conditional, not LINUX.
Use INADDR_NONE instead of -1 to check inet_addr() result
Roberto C. Sanchez:
Diff opts typo fix.
Yann Dirson:
Call cvs with -q flag when fetching the log
Dependency handling
* to-check additionally has:
Linus Torvalds:
Make time ordering less important than revision ordering
* dev branches still have incomplete stuff, so I don't list it
here.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Collecting cvsps patches
From: Yann Dirson @ 2006-06-16 21:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Mansfield, Pavel Roskin, GIT list, cvsps
In-Reply-To: <Pine.LNX.4.64.0606130841200.5498@g5.osdl.org>
On Tue, Jun 13, 2006 at 08:47:15AM -0700, Linus Torvalds wrote:
>
> On Tue, 13 Jun 2006, Yann Dirson wrote:
> >
> > I have setup a Q&D page at
> > http://ydirson.free.fr/en/software/scm/cvsps.html to link to.
> >
> > I'll expand it later with more information.
>
> Will you be able to set up gitweb on that site, perhaps?
No, CGI's on this hosting platform are restricted to ISP-provided
ones.
Do you think it would be adequate to have this repo hosted on
kernel.org ?
> Also, I guess that patch I posted in the "cvsps wierdness" thread (yeah,
> yeah, bad spelling, but it wasn't me who started the thread) should
> probably be added, since it fixed at least one test-case.
>
> Although it should probably get more testing with a bigger and more
> real-life repository..
Added, in the to-check branch. At least the idea is sound.
Anyway, there are quite a number of hairy repos out there, which
appear to cause problem to cvsps. I'll see if I can identify more
problems precisely - I have already collected a handful of them to
http://bugs.debian.org/cvsps.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Collecting cvsps patches
From: Jakub Narebski @ 2006-06-16 21:31 UTC (permalink / raw)
To: git
In-Reply-To: <20060616212334.GN7766@nowhere.earth>
Yann Dirson wrote:
> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>
>> > http://ydirson.free.fr/soft/git/cvsps.git
>>
>> I think you need to chmod +x hooks/post-update
>>
>> and then run 'git-update-server-info'.
>
> Unfortunately, I only have FTP access to push to this site, so I have
> to run git-update-server-info myself, and occasionally forget. I'll
> have to bring up-to-date my old cg-ftppush script some day :)
Or extend git to allow push/pull also via ftp?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Junio C Hamano @ 2006-06-16 21:25 UTC (permalink / raw)
To: David Kowis; +Cc: git
In-Reply-To: <4492E8F9.4000106@shlrm.org>
David Kowis <dkowis@shlrm.org> writes:
> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
> Author: David Kowis <dkowis@kain.org>
> Date: Fri Jun 16 12:20:08 2006 -0500
>
> this is a multi
>
> line comment
> with three lines
>
>
> I'm using git 1.4.0. It added a blank line in there...
Actually, this is an odd but intended behaviour ;-).
^ permalink raw reply
* Re: Collecting cvsps patches
From: Yann Dirson @ 2006-06-16 21:23 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <e6jj39$6ua$1@sea.gmane.org>
On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>
> > http://ydirson.free.fr/soft/git/cvsps.git
>
> I think you need to chmod +x hooks/post-update
>
> and then run 'git-update-server-info'.
Unfortunately, I only have FTP access to push to this site, so I have
to run git-update-server-info myself, and occasionally forget. I'll
have to bring up-to-date my old cg-ftppush script some day :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: H. Peter Anvin @ 2006-06-16 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0606152335130.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> Actually, the really irritating thing is that we actually generate all
> these nice status updates, which just makes pulling and cloning a lot more
> comfortable, because you actually see what is going on, and what to
> expect.
>
> Except they only work over ssh, where we have a separate channel (for
> stderr), and with the native git protocol all that nice status work just
> gets flushed to /dev/null :(
>
> Dang. It's literally the most irritating part of the thing: the protocol
> itself is exactly the same whether you go over ssh:// or over git://, but
> that visual information about what is going on is missing, and it's
> surprisingly important from a usability standpoint.
>
Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of the
protocol itself. After all, the protocol already does packetization, so all it needs is a
reliable way to pick out the error/status packets; we could even combine that with a
machine-readable code (like SMTP et al) that could get interpreted by the other side as
needed.
-hpa
^ permalink raw reply
* Re: Autoconf/Automake
From: Petr Baudis @ 2006-06-16 20:42 UTC (permalink / raw)
To: Yann Dirson; +Cc: Johannes Schindelin, Phil Richards, git
In-Reply-To: <20060616201715.GM7766@nowhere.earth>
Dear diary, on Fri, Jun 16, 2006 at 10:17:15PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:
> > > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > > > As for now, I fail to see why the current system is not adequate for git!
> > >
> > > I can reassure you, gazillions of people still fail to see why cvs is
> > > not adequate for their project. And the ratio of devs in the
> > > corporate world not knowning git to those not knowning cvs is far
> > > superior to 2. And everyone here knows cvs is not more adequate than
> > > git for so many tasks :)
> >
> > You know as well as I that this comparison is unfair. I am _NOT_ a
> > corporate person. I hope that you do not judge me as a complete airhead.
>
> Well, I have to apologize - especially after looking closer at the
> current Makefile. I think I understand now why autoconf was suggested
> in the first place, but it what it would achieve would mostly moving
> the ifdef's to configure.ac, which would not be such a gain anyway.
Except that then I don't need to bother manually adding NO_EXPAT to the
makefile on all systems I compile git on.
Yes, it's not a huge bother per se, but since almost all other
non-obscure projects do figure these things out automagically, git kind
of stands out negatively here. "Wah, it needs me tweak the Makefile to
be able to compile it."
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Autoconf/Automake
From: Yann Dirson @ 2006-06-16 20:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Phil Richards, git
In-Reply-To: <Pine.LNX.4.63.0606160053560.7480@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:
> > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > > As for now, I fail to see why the current system is not adequate for git!
> >
> > I can reassure you, gazillions of people still fail to see why cvs is
> > not adequate for their project. And the ratio of devs in the
> > corporate world not knowning git to those not knowning cvs is far
> > superior to 2. And everyone here knows cvs is not more adequate than
> > git for so many tasks :)
>
> You know as well as I that this comparison is unfair. I am _NOT_ a
> corporate person. I hope that you do not judge me as a complete airhead.
Well, I have to apologize - especially after looking closer at the
current Makefile. I think I understand now why autoconf was suggested
in the first place, but it what it would achieve would mostly moving
the ifdef's to configure.ac, which would not be such a gain anyway.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Running parse cvs
From: Johannes Schindelin @ 2006-06-16 19:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, git, Keith Packard
In-Reply-To: <Pine.LNX.4.64.0606161220360.5498@g5.osdl.org>
Hi,
On Fri, 16 Jun 2006, Linus Torvalds wrote:
> Valgrind is da bomb.
Now you are officially on the NSA black list.
^ permalink raw reply
* Re: Running parse cvs
From: Linus Torvalds @ 2006-06-16 19:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: git, Keith Packard
In-Reply-To: <9e4733910606161147m403a3f36r6657bd7b620958f3@mail.gmail.com>
On Fri, 16 Jun 2006, Jon Smirl wrote:
>
> I am running the latest parsecvs from your git tree. I am hitting a quick gpf.
If it's really quick, run it under valgrind. It will slow down things
enormously, but if it happens early on, you won't care, and it will
generally give a much better reason for why the problem happened than the
glibc malloc debugger will.
Ie just
valgrind --tool=memcheck parsecvs ..
should do it.
Valgrind is da bomb.
Linus
^ permalink raw reply
* Re: Running parse cvs
From: Jon Smirl @ 2006-06-16 19:10 UTC (permalink / raw)
To: git, Keith Packard
In-Reply-To: <9e4733910606161147m403a3f36r6657bd7b620958f3@mail.gmail.com>
On 6/16/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> I am running the latest parsecvs from your git tree. I am hitting a quick gpf.
>
> oad: sible/src/html/nsHTMLLinkAccessible *.................... 253 of 100111
> Load: essible/src/html/nsHTMLLinkAccessib *.................... 254 of 100111
> Load: ble/src/html/nsHTMLSelectAccessible *.................... 255 of 100111
> *** glibc detected *** /home/jonsmirl/workspace/parsecvs/parsecvs:
> munmap_chunk(): invalid pointer: 0x08fd1db0 ***
>
> In the call stack I am in git_rev_list_pack line 619 doing a free.
> Called from parsecvs.c at 776
The GPF is because git-Pack_directory is calling free(git_dir) when
git_dir is an atom.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Running parse cvs
From: Jon Smirl @ 2006-06-16 18:47 UTC (permalink / raw)
To: git, Keith Packard
I am running the latest parsecvs from your git tree. I am hitting a quick gpf.
oad: sible/src/html/nsHTMLLinkAccessible *.................... 253 of 100111
Load: essible/src/html/nsHTMLLinkAccessib *.................... 254 of 100111
Load: ble/src/html/nsHTMLSelectAccessible *.................... 255 of 100111
*** glibc detected *** /home/jonsmirl/workspace/parsecvs/parsecvs:
munmap_chunk(): invalid pointer: 0x08fd1db0 ***
In the call stack I am in git_rev_list_pack line 619 doing a free.
Called from parsecvs.c at 776
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Why so much time in the kernel?
From: Linus Torvalds @ 2006-06-16 18:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606161000t53328571u10a350eca894ccdc@mail.gmail.com>
On Fri, 16 Jun 2006, Jon Smirl wrote:
>
> Is it a crazy idea to read the cvs files, compute an sha1 on each
> expanded delta and then write the delta straight into a pack file? Are
> the cvs and git delta formats the same? What about CVS's forward and
> reverse delta use? While this is going on, track the
> branches/changsets in memory and then finish up by writing these trees
> into the pack file too. This should take no more ram than cvsps needs
> currently.
What you want is parsecvs, which does it much more like that.
Linus
^ permalink raw reply
* Re: Autoconf/Automake
From: Petr Baudis @ 2006-06-16 18:31 UTC (permalink / raw)
To: Yann Dirson; +Cc: Johannes Schindelin, Phil Richards, git
In-Reply-To: <20060615220534.GL7766@nowhere.earth>
Dear diary, on Fri, Jun 16, 2006 at 12:05:34AM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > As for now, I fail to see why the current system is not adequate for git!
>
> I can reassure you, gazillions of people still fail to see why cvs is
> not adequate for their project. And the ratio of devs in the
> corporate world not knowning git to those not knowning cvs is far
> superior to 2. And everyone here knows cvs is not more adequate than
> git for so many tasks :)
Duh. That works the same way when I replace the original question with
"As for now, I fail to see to see why Linux is not adequate for my
desktop! (In contrast with AIX.)".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Autoconf/Automake
From: Petr Baudis @ 2006-06-16 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6s7eb$78h$1@sea.gmane.org>
Dear diary, on Thu, Jun 15, 2006 at 08:03:56PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Does autoconf generate configure script in POSIX shell, or in bash?
/bin/sh, but on such a degree that it avoids using even functions -
which makes the resulting ./configure script quite awful. autoconf is
*much* better than automake (libtool I shall refrain commenting on
entirely; eeeek) in that you have much more free hand in bending it
in case it does something stupid, but the resulting ./configure script
is still mammoth and barely readable.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Why so much time in the kernel?
From: Nicolas Pitre @ 2006-06-16 18:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, Linus Torvalds, git
In-Reply-To: <9e4733910606161044h736c9675kc91ff77904c5a1d0@mail.gmail.com>
On Fri, 16 Jun 2006, Jon Smirl wrote:
> On 6/16/06, Keith Packard <keithp@keithp.com> wrote:
> > On Fri, 2006-06-16 at 13:00 -0400, Jon Smirl wrote:
> > > Is it a crazy idea to read the cvs files, compute an sha1 on each
> > > expanded delta and then write the delta straight into a pack file? Are
> > > the cvs and git delta formats the same? What about CVS's forward and
> > > reverse delta use?
> >
> > At this point, merging blobs into packs isn't a significant part of the
> > computational cost. parsecvs is spending all of its time in the
> > quadratic traversal of the diff chains; fixing that to emit all of the
> > versions in a single pass should speed up that part of the conversion
> > process dramatically.
>
> That's not true for the state I am in. cvsps can compute the changeset
> tree in 15 minutes, cvs2svn can compute their version in a couple of
> hours. cvs2svn builds a much better tree.
Did you try parsecvs recently?
Nicolas
^ permalink raw reply
* Re: Why so much time in the kernel?
From: Keith Packard @ 2006-06-16 18:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Linus Torvalds, git
In-Reply-To: <9e4733910606161044h736c9675kc91ff77904c5a1d0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
On Fri, 2006-06-16 at 13:44 -0400, Jon Smirl wrote:
> I've been extracting versions from cvs and adding them to git now for
> 2.5 days and the process still isn't finished. It is completely CPU
> bound. It's just a loop of cvs co, add it to git, make tree, commit,
> etc.
To do all of mozilla using parsecvs (even with the quadratic algorithm)
takes about three hours on annarchy.freedesktop.org (two dual-core
Opteron with 4GB memory), including all conversion to packs. The pack
time is a tiny fraction of that.
> What about the cvs2svn algorithm described in the attachment? A ram
> based version could be faster. Compression could be acheived by
> switching from using the full path to a version to the sha1 for it.
Yes, parsecvs currently keeps everything in memory when doing the tree
conversion, which means it grows to a huge size to compute the full tree
of revisions. Computing git tree objects from the top down, then
computing commit objects from the bottom up should allow us to free most
of that during the full branch history computation process. I'm starting
a rewrite of parsecvs to try this approach and see how well it works.
If you've looked at the parsecvs source code, you'll notice it's a mess
at present; I started by attempting to do pair-wise tree merges in a
mistaken attempt to convert a linear term to log. Hacking that code into
its present form should be viewed more as a demonstration of how the
overall process can work, not as an optimal expression of the algorithm.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 4/4] git-svn: rebuild convenience and bugfixes
From: Eric Wong @ 2006-06-16 17:57 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11504806492195-git-send-email-normalperson@yhbt.net>
We will now automatically fetch the refs/remotes/git-svn ref
from origin and store a Pull: line for it.
--remote=<origin> may be passed if your remote is named something
other than 'origin'
Also, remember to make GIT_SVN_DIR whenever we need to create
.rev_db
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index ab1d065..da0ff9a 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -42,7 +42,7 @@ my $_optimize_commits = 1 unless $ENV{GI
my $sha1 = qr/[a-f\d]{40}/;
my $sha1_short = qr/[a-f\d]{4,40}/;
my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
- $_find_copies_harder, $_l, $_cp_similarity,
+ $_find_copies_harder, $_l, $_cp_similarity, $_cp_remote,
$_repack, $_repack_nr, $_repack_flags,
$_template, $_shared, $_no_default_regex, $_no_graft_copy,
$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
@@ -86,6 +86,7 @@ my %cmd = (
{ 'revision|r=i' => \$_revision } ],
rebuild => [ \&rebuild, "Rebuild git-svn metadata (after git clone)",
{ 'no-ignore-externals' => \$_no_ignore_ext,
+ 'copy-remote|remote=s' => \$_cp_remote,
'upgrade' => \$_upgrade } ],
'graft-branches' => [ \&graft_branches,
'Detect merges/branches from already imported history',
@@ -134,7 +135,7 @@ init_vars();
load_authors() if $_authors;
load_all_refs() if $_branch_all_refs;
svn_compat_check();
-migration_check() unless $cmd =~ /^(?:init|multi-init)$/;
+migration_check() unless $cmd =~ /^(?:init|rebuild|multi-init)$/;
$cmd{$cmd}->[0]->(@ARGV);
exit 0;
@@ -174,6 +175,9 @@ sub version {
}
sub rebuild {
+ if (quiet_run(qw/git-rev-parse --verify/,"refs/remotes/$GIT_SVN^0")) {
+ copy_remote_ref();
+ }
$SVN_URL = shift or undef;
my $newest_rev = 0;
if ($_upgrade) {
@@ -1940,6 +1944,7 @@ sub svn_cmd_checkout {
sub check_upgrade_needed {
if (!-r $REVDB) {
+ -d $GIT_SVN_DIR or mkpath([$GIT_SVN_DIR]);
open my $fh, '>>',$REVDB or croak $!;
close $fh;
}
@@ -2052,6 +2057,7 @@ sub migrate_revdb {
init_vars();
exit 0 if -r $REVDB;
print "Upgrading svn => git mapping...\n";
+ -d $GIT_SVN_DIR or mkpath([$GIT_SVN_DIR]);
open my $fh, '>>',$REVDB or croak $!;
close $fh;
rebuild();
@@ -2763,6 +2769,17 @@ sub revdb_get {
return $ret;
}
+sub copy_remote_ref {
+ my $origin = $_cp_remote ? $_cp_remote : 'origin';
+ my $ref = "refs/remotes/$GIT_SVN";
+ if (safe_qx('git-ls-remote', $origin, $ref)) {
+ sys(qw/git fetch/, $origin, "$ref:$ref");
+ } else {
+ die "Unable to find remote reference: ",
+ "refs/remotes/$GIT_SVN on $origin\n";
+ }
+}
+
package SVN::Git::Editor;
use vars qw/@ISA/;
use strict;
--
1.4.0
^ permalink raw reply related
* [PATCH 3/4] git-svn: svn (command-line) 1.0.x compatibility
From: Eric Wong @ 2006-06-16 17:57 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11504806481800-git-send-email-normalperson@yhbt.net>
Tested on a plain Ubuntu Warty installation
using subversion 1.0.6-1.2ubuntu3
svn add --force was never needed, as it only affected
directories, which git (thankfully) doesn't track
The 1.0.x also didn't support symlinks(!), so allow NO_SYMLINK
to be defined for running tests
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 4 +
contrib/git-svn/t/t0000-contrib-git-svn.sh | 90 +++++++++++++++-------------
2 files changed, 51 insertions(+), 43 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 417fcf1..ab1d065 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -1306,12 +1306,12 @@ sub svn_checkout_tree {
} elsif ($m->{chg} eq 'T') {
sys(qw(svn rm --force),$m->{file_b});
apply_mod_line_blob($m);
- sys(qw(svn add --force), $m->{file_b});
+ sys(qw(svn add), $m->{file_b});
svn_check_prop_executable($m);
} elsif ($m->{chg} eq 'A') {
svn_ensure_parent_path( $m->{file_b} );
apply_mod_line_blob($m);
- sys(qw(svn add --force), $m->{file_b});
+ sys(qw(svn add), $m->{file_b});
svn_check_prop_executable($m);
} else {
croak "Invalid chg: $m->{chg}\n";
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/contrib/git-svn/t/t0000-contrib-git-svn.sh
index 0f52746..443d518 100644
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/contrib/git-svn/t/t0000-contrib-git-svn.sh
@@ -11,7 +11,10 @@ mkdir import
cd import
echo foo > foo
-ln -s foo foo.link
+if test -z "$NO_SYMLINK"
+then
+ ln -s foo foo.link
+fi
mkdir -p dir/a/b/c/d/e
echo 'deep dir' > dir/a/b/c/d/e/file
mkdir -p bar
@@ -129,46 +132,45 @@ test_expect_success "$name" \
-name='executable file becomes a symlink to bar/zzz (file)'
-rm exec.sh
-ln -s bar/zzz exec.sh
-git update-index exec.sh
-git commit -m "$name"
-
-test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -L $SVN_TREE/exec.sh"
-
-
-
-name='new symlink is added to a file that was also just made executable'
-chmod +x bar/zzz
-ln -s bar/zzz exec-2.sh
-git update-index --add bar/zzz exec-2.sh
-git commit -m "$name"
-
-test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -x $SVN_TREE/bar/zzz &&
- test -L $SVN_TREE/exec-2.sh"
-
-
-
-name='modify a symlink to become a file'
-git help > help || true
-rm exec-2.sh
-cp help exec-2.sh
-git update-index exec-2.sh
-git commit -m "$name"
-
-test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -f $SVN_TREE/exec-2.sh &&
- test ! -L $SVN_TREE/exec-2.sh &&
- diff -u help $SVN_TREE/exec-2.sh"
+if test -z "$NO_SYMLINK"
+then
+ name='executable file becomes a symlink to bar/zzz (file)'
+ rm exec.sh
+ ln -s bar/zzz exec.sh
+ git update-index exec.sh
+ git commit -m "$name"
+
+ test_expect_success "$name" \
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
+ svn up $SVN_TREE &&
+ test -L $SVN_TREE/exec.sh"
+
+ name='new symlink is added to a file that was also just made executable'
+ chmod +x bar/zzz
+ ln -s bar/zzz exec-2.sh
+ git update-index --add bar/zzz exec-2.sh
+ git commit -m "$name"
+
+ test_expect_success "$name" \
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
+ svn up $SVN_TREE &&
+ test -x $SVN_TREE/bar/zzz &&
+ test -L $SVN_TREE/exec-2.sh"
+
+ name='modify a symlink to become a file'
+ git help > help || true
+ rm exec-2.sh
+ cp help exec-2.sh
+ git update-index exec-2.sh
+ git commit -m "$name"
+
+ test_expect_success "$name" \
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
+ svn up $SVN_TREE &&
+ test -f $SVN_TREE/exec-2.sh &&
+ test ! -L $SVN_TREE/exec-2.sh &&
+ diff -u help $SVN_TREE/exec-2.sh"
+fi
if test -n "$GIT_SVN_LC_ALL" && echo $GIT_SVN_LC_ALL | grep -q '\.UTF-8$'
@@ -193,6 +195,12 @@ test_expect_success "$name" \
git-rev-list --pretty=raw remotes/alt | grep ^tree | uniq > b &&
diff -u a b"
+if test -n "$NO_SYMLINK"
+then
+ test_done
+ exit 0
+fi
+
name='check imported tree checksums expected tree checksums'
rm -f expected
if test -n "$GIT_SVN_LC_ALL" && echo $GIT_SVN_LC_ALL | grep -q '\.UTF-8$'
--
1.4.0
^ permalink raw reply related
* [PATCH 2/4] git-svn: tests no longer fail if LC_ALL is not a UTF-8 locale
From: Eric Wong @ 2006-06-16 17:57 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11504806472857-git-send-email-normalperson@yhbt.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/Makefile | 5 +++--
contrib/git-svn/t/t0000-contrib-git-svn.sh | 8 ++++++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index d73aa56..6aedb10 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -32,9 +32,10 @@ test: git-svn
cd t && $(SHELL) ./t0000-contrib-git-svn.sh $(TEST_FLAGS)
cd t && $(SHELL) ./t0001-contrib-git-svn-props.sh $(TEST_FLAGS)
+# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
full-test:
- $(MAKE) test GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1
- $(MAKE) test GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1
+ $(MAKE) test GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
+ $(MAKE) test GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
$(MAKE) test GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
LC_ALL=en_US.UTF-8
$(MAKE) test GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/contrib/git-svn/t/t0000-contrib-git-svn.sh
index f896e2c..0f52746 100644
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/contrib/git-svn/t/t0000-contrib-git-svn.sh
@@ -194,8 +194,12 @@ test_expect_success "$name" \
diff -u a b"
name='check imported tree checksums expected tree checksums'
-cat > expected <<\EOF
-tree f735671b89a7eb30cab1d8597de35bd4271ab813
+rm -f expected
+if test -n "$GIT_SVN_LC_ALL" && echo $GIT_SVN_LC_ALL | grep -q '\.UTF-8$'
+then
+ echo tree f735671b89a7eb30cab1d8597de35bd4271ab813 > expected
+fi
+cat >> expected <<\EOF
tree 4b9af72bb861eaed053854ec502cf7df72618f0f
tree 031b8d557afc6fea52894eaebb45bec52f1ba6d1
tree 0b094cbff17168f24c302e297f55bfac65eb8bd3
--
1.4.0
^ permalink raw reply related
* [PATCH 0/4] git-svn: more improvements
From: Eric Wong @ 2006-06-16 17:57 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <11504049343825-git-send-email-normalperson@yhbt.net>
Another round of patches to git-svn, all depending on previous patches.
I've also setup a pullable repo here for all my latest git-svn stuff:
git://git.bogomips.org/git-svn.git
(http:// also works)
--
Eric Wong
^ permalink raw reply
* [PATCH 1/4] git-svn: bugfix and optimize the 'log' command
From: Eric Wong @ 2006-06-16 17:57 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11504806463470-git-send-email-normalperson@yhbt.net>
Revisions with long commit messages were being skipped, since
the 'git-svn-id' metadata line was at the end and git-log uses a
32k buffer to print the commits.
Also the last 'git-svn-id' metadata line in a commit is always
the valid one, so make sure we use that, as well.
Made the verbose flag work by passing the correct option switch
('--summary') to git-log.
Finally, optimize -r/--revision argument handling by passing
the appropriate limits to revision
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 60 ++++++++++++++++++++++++++++++++++++------
1 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 149149f..417fcf1 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -663,17 +663,15 @@ sub show_log {
my $pid = open(my $log,'-|');
defined $pid or croak $!;
if (!$pid) {
- my @rl = (qw/git-log --abbrev-commit --pretty=raw
- --default/, "remotes/$GIT_SVN");
- push @rl, '--raw' if $_verbose;
- exec(@rl, @args) or croak $!;
+ exec(git_svn_log_cmd($r_min,$r_max), @args) or croak $!;
}
setup_pager();
my (@k, $c, $d);
+
while (<$log>) {
if (/^commit ($sha1_short)/o) {
my $cmt = $1;
- if ($c && defined $c->{r} && $c->{r} != $r_last) {
+ if ($c && cmt_showable($c) && $c->{r} != $r_last) {
$r_last = $c->{r};
process_commit($c, $r_min, $r_max, \@k) or
goto out;
@@ -692,8 +690,7 @@ sub show_log {
} elsif ($d) {
push @{$c->{diff}}, $_;
} elsif (/^ (git-svn-id:.+)$/) {
- my ($url, $rev, $uuid) = extract_metadata($1);
- $c->{r} = $rev;
+ (undef, $c->{r}, undef) = extract_metadata($1);
} elsif (s/^ //) {
push @{$c->{l}}, $_;
}
@@ -715,6 +712,52 @@ out:
########################### utility functions #########################
+sub cmt_showable {
+ my ($c) = @_;
+ return 1 if defined $c->{r};
+ if ($c->{l} && $c->{l}->[-1] eq "...\n" &&
+ $c->{a_raw} =~ /\@([a-f\d\-]+)>$/) {
+ my @msg = safe_qx(qw/git-cat-file commit/, $c->{c});
+ shift @msg while ($msg[0] ne "\n");
+ shift @msg;
+ @{$c->{l}} = grep !/^git-svn-id: /, @msg;
+
+ (undef, $c->{r}, undef) = extract_metadata(
+ (grep(/^git-svn-id: /, @msg))[-1]);
+ }
+ return defined $c->{r};
+}
+
+sub git_svn_log_cmd {
+ my ($r_min, $r_max) = @_;
+ my @cmd = (qw/git-log --abbrev-commit --pretty=raw
+ --default/, "refs/remotes/$GIT_SVN");
+ push @cmd, '--summary' if $_verbose;
+ return @cmd unless defined $r_max;
+ if ($r_max == $r_min) {
+ push @cmd, '--max-count=1';
+ if (my $c = revdb_get($REVDB, $r_max)) {
+ push @cmd, $c;
+ }
+ } else {
+ my ($c_min, $c_max);
+ $c_max = revdb_get($REVDB, $r_max);
+ $c_min = revdb_get($REVDB, $r_min);
+ if ($c_min && $c_max) {
+ if ($r_max > $r_max) {
+ push @cmd, "$c_min..$c_max";
+ } else {
+ push @cmd, "$c_max..$c_min";
+ }
+ } elsif ($r_max > $r_min) {
+ push @cmd, $c_max;
+ } else {
+ push @cmd, $c_min;
+ }
+ }
+ return @cmd;
+}
+
sub fetch_child_id {
my $id = shift;
print "Fetching $id\n";
@@ -2206,6 +2249,7 @@ sub setup_pager { # translated to Perl f
sub get_author_info {
my ($dest, $author, $t, $tz) = @_;
$author =~ s/(?:^\s*|\s*$)//g;
+ $dest->{a_raw} = $author;
my $_a;
if ($_authors) {
$_a = $rusers{$author} || undef;
@@ -2440,7 +2484,7 @@ sub svn_grab_base_rev {
close $fh;
if (defined $c && length $c) {
my ($url, $rev, $uuid) = extract_metadata((grep(/^git-svn-id: /,
- safe_qx(qw/git-cat-file commit/, $c)))[0]);
+ safe_qx(qw/git-cat-file commit/, $c)))[-1]);
return ($rev, $c);
}
return (undef, undef);
--
1.4.0
^ permalink raw reply related
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