git-svn does not seems to work with crlf convertion enabled.

Hello list.

In short: I can't clone svn repo into git when crlf convertion is activated.

Long story.
I use latest git: 
$ git version
git version 1.5.6.4

For a long period of time I use git at work. Main repo is svn-powered and I 
use git-svn for linking git and svn. The project itself is a windows cpp 
project. I use git under Linux machine (Debian etch with manually backported 
git from sid) and work with linux-hosted project thru samba. From the begin I 
did not enable crlf convertion and broke crlf notation in files one by one 
during my commits. My co-workers does not like this and finally I decide to 
try to use autocrlf feature of git. So I take a copy of my git repo and 
convert all text files to unix LF line endings:

git filter-branch --tree-filter "find -type f \( -iname '*.h' -or \
-iname '*.cpp' -or -iname '*.vcproj' -or -iname '*.sln' -or \
-iname '*.h.tmpl' -or -iname '*.bat' -or -iname '*.mp' -or \
-iname '*.txt' -or -iname '*.nsi' -or -iname '*.def' -or \
-iname '*.rc' -or -iname '*.ini' -or -iname '*.inf' -or \
-iname '*.skin' -or -iname '*.c' -or -iname '*.dsp' \
-or -iname '*.dsw' \) -print0 | xargs -r0 dos2unix" \
`git branch -a | sed 's/^..//'`

It finished succefully. After fish I have added  .git/info/attributes like 
this:
*               -crlf
*.h             crlf
*.c             crlf
*.cpp           crlf
and so on...
and add set core.autocrlf to true and safecrlf to false. Also I cleared all 
git-svn's caches:
rm -rf .git/svn

As I understand I got pure repo that is capable to work with crlf convertion. 
Lets update it (on branch forked from trunk): git svn rebase
<.. some long list of revs during migration to new git-svn layout..>
Done rebuilding .git/svn/trunk/.rev_map.f1f59411-8b2e-0410-9ee3-aa470c928bf2
        M       FindHistory.cpp
Incomplete data: Delta source ended unexpectedly at /tmp/g/bin/git-svn line 
3856

Oops ! Whats this ? I am not able to update. I can update other branches but 
not trunk.

So I have to try my old original repo without crlf convertion enabled. It was 
updated succeffuly, I cant show log it was lost and I was not able to 
reproduce it.



Is there any way to fix this problem ?

P.S. I can't even clone that svn repo from scratch with crlf convertion 
enabled.

Hi,

On Wed, 23 Jul 2008, Alexander Litvinov wrote:

In short: I can't clone svn repo into git when crlf convertion is 
activated.

This is a known issue, but since nobody with that itch seems to care 
enough to fix it, I doubt it will ever be fixed.

Ciao,
Dscho

On Wed, 23 Jul 2008, Alexander Litvinov wrote:

quoted

In short: I can't clone svn repo into git when crlf convertion is
activated.

This is a known issue, but since nobody with that itch seems to care
enough to fix it, I doubt it will ever be fixed.

That is a bad news for me. Anyway I will spend some time at holidays during 
digging this bug. 

Hi,

On Wed, 23 Jul 2008, Alexander Litvinov wrote:

quoted

On Wed, 23 Jul 2008, Alexander Litvinov wrote:

quoted

In short: I can't clone svn repo into git when crlf convertion is 
activated.

This is a known issue, but since nobody with that itch seems to care 
enough to fix it, I doubt it will ever be fixed.

That is a bad news for me. Anyway I will spend some time at holidays 
during digging this bug.

Note that you will have to do your digging using msysGit (i.e. the 
developer's pack, not the installer for plain Git), since git-svn will be 
removed from the next official "Windows Git" release, due to lack of 
fixers.

Ciao,
Dscho

On 7/23/08, Johannes Schindelin [off-list ref] wrote:

 On Wed, 23 Jul 2008, Alexander Litvinov wrote:
 > > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
 > > > In short: I can't clone svn repo into git when crlf convertion is
 > > > activated.
 > >
 > > This is a known issue, but since nobody with that itch seems to care
 > > enough to fix it, I doubt it will ever be fixed.
 >
 > That is a bad news for me. Anyway I will spend some time at holidays
 > during digging this bug.

Note that you will have to do your digging using msysGit (i.e. the
 developer's pack, not the installer for plain Git), since git-svn will be
 removed from the next official "Windows Git" release, due to lack of
 fixers.

Presumably cygwin git will work too, right?

Does this known issue apply only to msysGit, or both msys and Cygwin,
or all versions?  ie. could it be debugged on Linux?

Thanks,

Avery

Hi,

On Wed, 23 Jul 2008, Avery Pennarun wrote:

On 7/23/08, Johannes Schindelin [off-list ref] wrote:

quoted

 On Wed, 23 Jul 2008, Alexander Litvinov wrote:
 > > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
 > > > In short: I can't clone svn repo into git when crlf convertion 
 > > > is activated.
 > >
 > > This is a known issue, but since nobody with that itch seems to 
 > > care enough to fix it, I doubt it will ever be fixed.
 >
 > That is a bad news for me. Anyway I will spend some time at 
 > holidays during digging this bug.

Note that you will have to do your digging using msysGit (i.e. the 
developer's pack, not the installer for plain Git), since git-svn will 
be removed from the next official "Windows Git" release, due to lack 
of fixers.

Presumably cygwin git will work too, right?

Yes.

Does this known issue apply only to msysGit, or both msys and Cygwin, or 
all versions?  ie. could it be debugged on Linux?

You mean the crlf vs git-svn issue?  No, yes, yes, yes, and yes.

Ciao,
Dscho

Note that you will have to do your digging using msysGit (i.e. the
developer's pack, not the installer for plain Git), since git-svn will be
removed from the next official "Windows Git" release, due to lack of
fixers.

You will not believe me. I use git under Linux, develop under windows on 
network drive :-)

On Wed, Jul 23, 2008 at 06:52:09PM +0700, Alexander Litvinov wrote:

quoted

On Wed, 23 Jul 2008, Alexander Litvinov wrote:

quoted

In short: I can't clone svn repo into git when crlf convertion is
activated.

This is a known issue, but since nobody with that itch seems to care
enough to fix it, I doubt it will ever be fixed.

That is a bad news for me. Anyway I will spend some time at holidays during 
digging this bug. 

I don't want to discourage from digging into this problem, but there are
two reasons why no one has fixed this issue yet. First, configuration
CRLF conversion in Git and SVN is quite different, so it may not be easy
to have the solution that will work in all cases. Second, in many cases,
you can workaround this issue.

If I understood your situation correctly, you use SVN repo where text
files are marked with svn:eol-style=native. In this case, SVN stores
these files with LF endings internally, and git-svn receives files in
that format (at least, it is so on Debian).  Practically all Windows
editors do not have problems to open and edit files with LF endings, but
some of them will write back using CRLF. You do not want CRLF to get in
your Git repository, so you can do that by setting core.autocrlf=input.
This might work for you...

Dmitry

Hi,

On Thu, 24 Jul 2008, Dmitry Potapov wrote:

On Wed, Jul 23, 2008 at 06:52:09PM +0700, Alexander Litvinov wrote:

quoted

quoted

On Wed, 23 Jul 2008, Alexander Litvinov wrote:

quoted

In short: I can't clone svn repo into git when crlf convertion is 
activated.

This is a known issue, but since nobody with that itch seems to care 
enough to fix it, I doubt it will ever be fixed.

That is a bad news for me. Anyway I will spend some time at holidays 
during digging this bug.

I don't want to discourage from digging into this problem

Great.  Thanks.  There is someone who is actually willing to work on the 
problem.

Practically all Windows editors do not have problems to open and edit 
files with LF endings, but some of them will write back using CRLF.

95.23% of all statistics are made up on the spot.  I would be surprised if 
that was not the case here.

Ciao,
Dscho

On 7/24/08, Johannes Schindelin [off-list ref] wrote:

 On Thu, 24 Jul 2008, Dmitry Potapov wrote:
 > Practically all Windows editors do not have problems to open and edit
 > files with LF endings, but some of them will write back using CRLF.

95.23% of all statistics are made up on the spot.  I would be surprised if
 that was not the case here.

Without assigning a specific number, Dmitry's experience matches mine.
 I haven't seen an editor that can't *read* LF since notepad.  But
many of them happily mangle the files.

Of course, notepad is probably at least 50% of the editors most
Windows users actually use, on a per-transaction basis.

Have fun,

Avery

This is a known issue, but since nobody with that itch seems to care
enough to fix it, I doubt it will ever be fixed.

Hello again.

I have investigated this problem. Short result: git-svn and ANY file 
convertion will not work now.

In my case I have found the problem is the 
SVN::Git::Fetcher::apply_textdelta() function. To be more precicly call to 
SVN::TxDelta::apply(). We fetch previous version of file from git and then 
apply to it svn's delta. As far as we modify src file SVN fails to apply its 
delta. If I modify last commit and put original version of file everything 
works.

So it seems to me there are two solutions: 
1. Store original file somehow and use it to construct new file version;
2. In case of this error we could fetch full blob with new (or old) version of 
the file.

I did not find the way to gather full file conntent nor feel myself ready to 
rewrite git-svn to store original file somewhere.

Does anybody can help or comment on this ?

Make git-svn works with crlf (or any other) file content convertion enabled.

When we modify file content SVN cant apply its delta to it. To fix this
situation I take full file content from SVN as next revision. This is
dump and slow but it works.
---
 git-svn.perl |   34 +++++++++++++++++++---------------
 1 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..606a177 100755
--- a/git-svn.perl
+++ b/git-svn.perl

@@ -28,6 +28,7 @@ sub fatal (@) { print STDERR "@_\n"; exit 1 }
 require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
 require SVN::Ra;
 require SVN::Delta;
+require SVN::Client;
 if ($SVN::Core::VERSION lt '1.1.0') {
 	fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
 }

@@ -3075,6 +3076,7 @@ sub new {
 	my $self = SVN::Delta::Editor->new;
 	bless $self, $class;
 	$self->{c} = $git_svn->{last_commit} if exists $git_svn->{last_commit};
+	$self->{url} = $git_svn->{url};
 	$self->{empty} = {};
 	$self->{dir_prop} = {};
 	$self->{file_prop} = {};

@@ -3214,30 +3216,32 @@ sub change_file_prop {
 
 sub apply_textdelta {
 	my ($self, $fb, $exp) = @_;
-	my $fh = IO::File->new_tmpfile;
-	$fh->autoflush(1);
-	# $fh gets auto-closed() by SVN::TxDelta::apply(),
-	# (but $base does not,) so dup() it for reading in close_file
-	open my $dup, '<&', $fh or croak $!;
+
 	my $base = IO::File->new_tmpfile;
 	$base->autoflush(1);
 	if ($fb->{blob}) {
 		print $base 'link ' if ($fb->{mode_a} == 120000);
 		my $size = $::_repository->cat_blob($fb->{blob}, $base);
 		die "Failed to read object $fb->{blob}" if ($size < 0);
-
-		if (defined $exp) {
-			seek $base, 0, 0 or croak $!;
-			my $got = ::md5sum($base);
-			die "Checksum mismatch: $fb->{path} $fb->{blob}\n",
-			    "expected: $exp\n",
-			    "     got: $got\n" if ($got ne $exp);
-		}
 	}
 	seek $base, 0, 0 or croak $!;
-	$fb->{fh} = $dup;
+
+	my $fh = IO::File->new_tmpfile;
+	$fh->autoflush(1);
+
+	$fb->{fh} = $fh;
 	$fb->{base} = $base;
-	[ SVN::TxDelta::apply($base, $fh, undef, $fb->{path}, $fb->{pool}) ];
+
+	my $url = $self->{url};
+	$url =~ s/\/$//;
+	$url .= '/';
+	$url .= $fb->{path};
+
+	my $rev = $self->{file_prop}->{$fb->{path}}->{'svn:entry:committed-rev'};
+	die ("Can't find $fb->{path} revision") unless defined $rev;
+
+	my $ctx = SVN::Client->new();
+	$ctx->cat($fh, $url, $rev);
 }
 
 sub close_file {

-- 
1.5.6.2

Make git-svn works with crlf (or any other) file content convertion
enabled.

When we modify file content SVN cant apply its delta to it. To fix this
situation I take full file content from SVN as next revision. This is
dump and slow but it works.

Sorry for the noise. 

git-svn fetch files with this patch but I have found that git-svn use 
git-hash-object and provide file name to store into stdin. As far as file is 
a temp file git-hash-object can't correctly apply crlf convertion for the 
file.

As a conclusion: git-svn does not apply crlf convertion on files being stored 
into git repo. This make my patch useless.

On Thu, Jul 31, 2008 at 12:57:48PM +0700, Alexander Litvinov wrote:

git-svn fetch files with this patch but I have found that git-svn use 
git-hash-object and provide file name to store into stdin. As far as file is 
a temp file git-hash-object can't correctly apply crlf convertion for the 
file.

It does not look to be true. I did the following test:

mkdir hash_test
cd hash_test
git init

cat <<\=== > hash_test.pl
#!/usr/bin/env perl

use File::Temp qw/tempfile/;

my ($tmp_fh, $tmp_filename) = File::Temp::tempfile(UNLINK => 1);
print $tmp_fh "Hi\r\n";
$tmp_fh->flush;
system ("echo $tmp_filename | git hash-object --stdin-paths");
===

git config core.autocrlf true
perl hash_test.pl
git config core.autocrlf false
perl hash_test.pl


and the output was
b14df6442ea5a1b382985a6549b85d435376c351
ea6b6afbc2cbed0eb8c0f7561286ab72f349416c

which means that the autocrlf conversion is done for temporary
files created by perl. (I tested it on Linux and Windows/Cygwin).

In any case, I believe the right solution should be adding a
new option to git-hash-object to disable any conversion.

Dmitry

Hi All,

I am tryint to add the --no-filters option. It is useful for git-svn
and other importers that want to add file as-is without being affected
by any filter (in particular, autocrlf). Though, the patch below works,
I am not happy with the hackish way of passing no-filter requirement
to the index_fd() function. So, I wonder what would be preferable:
- to change 'write_object' to be flags (bit 0: write_object,
  bit 1: no-filters )
- to add some global the no_filters flag to environment.c, which can
  be checked inside of convert_to_git(), so it may be used in the
  future in some other cases (though I don't see where else it can
  be useful).

Another question: currently git hash-object --input imply no filters.
I don't know if it was done intentionally (it can be argued in both
ways). I don't think it is reasonable now to change this behavior,
so I want to add just one line to documentation, so there will be
no surprise among users.

Dmitry

-- 8< --
From: Dmitry Potapov <redacted>
Date: Thu, 31 Jul 2008 21:10:26 +0400
Subject: [PATCH] hash-object --no-filters

The --no-filters option makes git hash-object to work as there were no
input filters. This option is useful for importers such as git-svn to
put new version of files as is even if autocrlf is set.
---
 Documentation/git-hash-object.txt |    6 ++++++
 hash-object.c                     |    7 ++++++-
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index ac928e1..69a17c7 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt

@@ -35,6 +35,12 @@ OPTIONS
 --stdin-paths::
 	Read file names from stdin instead of from the command-line.
 
+--no-filters::
+	If this option is given then the file is hashed as is ignoring
+	all filters specified in the configuration, including crlf
+	conversion. If the file is read from standard input then no
+	filters is always implied.
+
 Author
 ------
 Written by Junio C Hamano <gitster@pobox.com>

diff --git a/hash-object.c b/hash-object.c
index 46c06a9..1e7fe8a 100644
--- a/hash-object.c
+++ b/hash-object.c

@@ -8,6 +8,8 @@
 #include "blob.h"
 #include "quote.h"
 
+static unsigned no_filters;
+
 static void hash_object(const char *path, enum object_type type, int write_object)
 {
 	int fd;

@@ -16,7 +18,8 @@ static void hash_object(const char *path, enum object_type type, int write_objec
 	fd = open(path, O_RDONLY);
 	if (fd < 0 ||
 	    fstat(fd, &st) < 0 ||
-	    index_fd(sha1, fd, &st, write_object, type, path))
+	    ((no_filters ? st.st_mode &= ~S_IFREG : 0),
+	     index_fd(sha1, fd, &st, write_object, type, path)))
 		die(write_object
 		    ? "Unable to add %s to database"
 		    : "Unable to hash %s", path);

@@ -104,6 +107,8 @@ int main(int argc, char **argv)
 					die("Multiple --stdin arguments are not supported");
 				hashstdin = 1;
 			}
+			else if (!strcmp(argv[i], "--no-filters"))
+				no_filters = 1;
 			else
 				usage(hash_object_usage);
 		}

-- 
1.6.0.rc1.32.gc84cb

It does not look to be true. I did the following test:

...

which means that the autocrlf conversion is done for temporary
files created by perl. (I tested it on Linux and Windows/Cygwin).

In any case, I believe the right solution should be adding a
new option to git-hash-object to disable any conversion.

My bad, I did not append full thoughts. git-hash-object DOES autocrlf 
convertion but  it cant do it correctly. All it can do - is to autodetect 
text files. My setup has .git/info/attributes file where all files but .cpp 
and .h are binary. While .cpp and .h are text files. In this case 
git-hash-object do not know the real file name as far as git-svn use 
temporary files.

I dont think that disabling convertion is a good way. I really want to convert 
my files. Possible solution is to pass two file names to git-hash-object: the 
real file with content and the proposed file name in the working directory. 
In this case git-hash-object will be able to make correct convertion.

On Fri, Aug 1, 2008 at 7:23 AM, Alexander Litvinov
[off-list ref] wrote:

I dont think that disabling convertion is a good way. I really want to convert
my files.

To being able to synchronize efficiently in both ways, you need to store
files exactly as they were received from SVN then there will be no
problem with applying binary delta patch. All CRLF conversion should be
done on checkout and checkin from/to Git repository.

Dmitry

Alexander Litvinov [off-list ref] wrote:

Make git-svn works with crlf (or any other) file content convertion enabled.

When we modify file content SVN cant apply its delta to it. To fix this
situation I take full file content from SVN as next revision. This is
dump and slow but it works.

+	my $ctx = SVN::Client->new();
+	$ctx->cat($fh, $url, $rev);
 }

I know you've already (at least for now) pulled this patch but I won't
accept anything that opens a second connection to the server.

I've seen this in some svn:// servers intermittently, but I've seen
git-svn get its connection terminated whenever it opens a second
connection (it happens with parent-following).  git-svn used to do
this more frequently, but most of those cases got fixed (but
one remains with parent-following).

Additionally, git-svnimport and older versions of git-svn used the
equivalent of $ctx->cat without deltas from the SVN::Ra object, so you
should be able todo something functionally equivalent w/o opening a new
socket.



As far as crlf issues with git-svn go, I'm blissfully ignorant of the
complexities behind what git (or svn for that matter) does with crlf
conversions[1].

I'll be alright with any changes to git-svn that don't modify existing
behavior for crlf-ignorant users such as myself.  I'll trust Junio and
other folks on the list to know and do what makes the most sense here.



[1] I would have much rather preferred git didn't implement or care
    about crlf filters at all, but maybe I'm just in a small minority.

-- 
Eric Wong

  Hi,

On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:

Note that you will have to do your digging using msysGit (i.e. the 
developer's pack, not the installer for plain Git), since git-svn will be 
removed from the next official "Windows Git" release, due to lack of 
fixers.

  is there any other problem with git-svn on Windows than the CRLF
issue? I couldn't find anything significant in the issue tracker.

  If not, why do you want to drop git-svn from Windows Git? It seems
that the CRLF issue has trivial workaround to set autocrlf=false;
this will make git-svn-tracked repositories useful only on Windows,
but I'd bet this is fine for large majority of Windows git-svn users?

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

On Wed, Aug 6, 2008 at 7:15 AM, Petr Baudis wrote:

On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:

quoted

Note that you will have to do your digging using msysGit (i.e. the
developer's pack, not the installer for plain Git), since git-svn will be
removed from the next official "Windows Git" release, due to lack of
fixers.

 is there any other problem with git-svn on Windows than the CRLF
issue? I couldn't find anything significant in the issue tracker.

The main problem currently is that git is Win32, and perl is Msys.
When perl asks git to read files from /tmp (a path that doesn't exist
outside Msys), it grinds to a screeching halt.

The quick and dirty fix is to convince git-svn to write temporary
files somewhere else (maybe by passing DIR => $ENV{GIT_DIR} to
File::Temp::tempname, but I've been too embarrassed to suggest that
publicly).

The correct fix is to switch the msysGit perl from Msys to Vanilla,
but I've been too lazy to finish that up (as the SVN modules quickly
descend into dependancy hell).

Peter Harris

Hi,

On Wed, 6 Aug 2008, Petr Baudis wrote:

On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:

quoted

Note that you will have to do your digging using msysGit (i.e. the 
developer's pack, not the installer for plain Git), since git-svn will 
be removed from the next official "Windows Git" release, due to lack 
of fixers.

  is there any other problem with git-svn on Windows than the CRLF
issue? I couldn't find anything significant in the issue tracker.

http://code.google.com/p/msysgit/issues/detail?id=120&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary

It is also frustrating that 

http://code.google.com/p/msysgit/issues/detail?id=83&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
http://code.google.com/p/msysgit/issues/detail?id=103&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
http://code.google.com/p/msysgit/issues/detail?id=129&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary

are probably the same issue.  I cannot only blame the users for not really 
looking if their issue has been reported yet; there are 32 open issues in 
msysGit right now, number increasing, so it gets quite confusing.

I once switched off the issue tracker, because I was the only one who took 
at least a little bit of care of it.  Due to list consensus, it was turned 
back on -- against my will.

Guess who takes care of it right now?

Exactly.  So I will soon be switching it off again, I think, because there 
are few more useless things than an unmonitored issue tracker.

  If not, why do you want to drop git-svn from Windows Git? It seems 
that the CRLF issue has trivial workaround to set autocrlf=false; this 
will make git-svn-tracked repositories useful only on Windows, but I'd 
bet this is fine for large majority of Windows git-svn users?

If it was so trivial, why does nobody use it?

Oh, and git-svn is slow, too.

And _noone_ of those competent Windows git-svn users seemed fit or willing 
to do anything about git-svn, not even the simplest of issues.

If you want to do something about it, go ahead.  But I have no inclination 
of hearing from any Windows user about git-svn again, ever.

Ciao,
Dscho

Hi!

On Wed, Aug 06, 2008 at 02:43:51PM +0200, Johannes Schindelin wrote:

On Wed, 6 Aug 2008, Petr Baudis wrote:

quoted

On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:

quoted

Note that you will have to do your digging using msysGit (i.e. the 
developer's pack, not the installer for plain Git), since git-svn will 
be removed from the next official "Windows Git" release, due to lack 
of fixers.

  is there any other problem with git-svn on Windows than the CRLF
issue? I couldn't find anything significant in the issue tracker.

http://code.google.com/p/msysgit/issues/detail?id=120&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary

Yes, that's why added the word "significant". ;-) This seems to be
simple module-out-of-sync issue.

It is also frustrating that 

http://code.google.com/p/msysgit/issues/detail?id=83&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
http://code.google.com/p/msysgit/issues/detail?id=103&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
http://code.google.com/p/msysgit/issues/detail?id=129&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary

are probably the same issue.  I cannot only blame the users for not really 
looking if their issue has been reported yet; there are 32 open issues in 
msysGit right now, number increasing, so it gets quite confusing.

I once switched off the issue tracker, because I was the only one who took 
at least a little bit of care of it.  Due to list consensus, it was turned 
back on -- against my will.

Guess who takes care of it right now?

Exactly.  So I will soon be switching it off again, I think, because there 
are few more useless things than an unmonitored issue tracker.

Well, when looking through the tracker earlier today, I actually wanted
to mark few dupes, but I did not find out how on the earth I'm supposed
to do that. Either the operation is well-hidden in the web interface or
I have to have some special rights to do that - in which case, it's no
wonder the tracker is deteriorating.

quoted

  If not, why do you want to drop git-svn from Windows Git? It seems 
that the CRLF issue has trivial workaround to set autocrlf=false; this 
will make git-svn-tracked repositories useful only on Windows, but I'd 
bet this is fine for large majority of Windows git-svn users?

If it was so trivial, why does nobody use it?

Because it is not documented? Or is it? *Searches crlf in git-svn.html
bundled with his msysgit* *Looks at Git FAQ* *Looks for release notes in
the start menu ... unsuccessfully* *Tries to Google out MSysGit release
notes ... unsuccessfully* *Founds MSysGit release notes sitting in
Program Files* "git svn is slow or seems to be broken (see discussions
on the mailing list)" What is "the" mailing list in MSysGit context?

*Googles out MSysGit Google Group* *Searches git-svn and pages... and
pages.*

	http://groups.google.com/group/msysgit/browse_thread/thread/8240da55a76f8c92/30656b448e9f5e74?lnk=gst&q=git-svn#30656b448e9f5e74

Okay. That was really easy to find, wasn't it... Somewhere deep inside,
even few mentions of autocrlf can be found.

Oh, and git-svn is slow, too.

And _noone_ of those competent Windows git-svn users seemed fit or willing 
to do anything about git-svn, not even the simplest of issues.

I can of course understand that argument, even though it's a bit sad to
see when the issues are apparently either trivial or there is simple
workaround available. My trouble was that the _concrete_ reasons for
this are buried deep inside long mail threads (or threads on other
mailing lists).

If you want to do something about it, go ahead.  But I have no inclination 
of hearing from any Windows user about git-svn again, ever.

Not currently, I'm just afraid I *might* have to sometime in the future.
;-)

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

On 8/6/08, Petr Baudis [off-list ref] wrote:

 On Wed, Aug 06, 2008 at 02:43:51PM +0200, Johannes Schindelin wrote:
 > And _noone_ of those competent Windows git-svn users seemed fit or willing
 > to do anything about git-svn, not even the simplest of issues.

 I can of course understand that argument, even though it's a bit sad to
 see when the issues are apparently either trivial or there is simple
 workaround available. My trouble was that the _concrete_ reasons for
 this are buried deep inside long mail threads (or threads on other
 mailing lists).

 > If you want to do something about it, go ahead.  But I have no inclination
 > of hearing from any Windows user about git-svn again, ever.

 Not currently, I'm just afraid I *might* have to sometime in the future.
 ;-)

FWIW (and related to the subject line in this thread), I think there
are a lot of git users on Windows who just use the cygwin one.  That's
what I do, and git-svn works fine (I don't use autocrlf though, which
is probably why it worked).  git's support for both platforms, and the
fact that cygwin was first and works already, probably greatly reduces
the number of developers who want to fix msysgit.

Have fun,

Avery

On Wed, Aug 6, 2008 at 3:15 PM, Petr Baudis [off-list ref] wrote:

 If not, why do you want to drop git-svn from Windows Git? It seems
that the CRLF issue has trivial workaround to set autocrlf=false;
this will make git-svn-tracked repositories useful only on Windows,
but I'd bet this is fine for large majority of Windows git-svn users?

Actually, it is not so simple. If you have svn properties setup correctly
for your text files (i.e. svn:eol-style=native) than autocrlf=false is
not what you want, because then SVN uses LF as EOL when stores this files.

In many case, just setting svn:eol-style correctly in SVN may solve the
problem.

However, to make git-svn work reliable in present files with different
ending, it should import files from SVN  without applying any filter.
Therefore, the --no-filters option was recently added to git-hash-object.
Adding its use to git-svn should be easy (I have not had time to test it):
===

diff --git a/perl/Git.pm b/perl/Git.pm
index 087d3d0..438b7fd 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm

@@ -829,7 +829,7 @@ sub _open_hash_and_insert_object_if_needed {

        ($self->{hash_object_pid}, $self->{hash_object_in},
         $self->{hash_object_out}, $self->{hash_object_ctx}) =
-               command_bidi_pipe(qw(hash-object -w --stdin-paths));
+               command_bidi_pipe(qw(hash-object -w --stdin-paths
--no-filters));
 }

 sub _close_hash_and_insert_object {

===

This should solve all problem with git-svn fetch. However, if you want to
respect svn:eol-style and when you commit your changes, that will require
synchronization svn:eol-style with values for crlf in your .gitattributes,
which is a much more ambitious task.

Dmitry