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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Petr Baudis
  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Peter Harris
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:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Johannes Schindelin
In reply to this post by Petr Baudis
Hi,

On Wed, 6 Aug 2008, Petr Baudis wrote:

> 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.

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

git-svn on MSysGit and why is it (going to be?) unsupported

Petr Baudis
Hi!

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

> On Wed, 6 Aug 2008, Petr Baudis wrote:
>
> > 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.
>
> 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.

> >   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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git-svn on MSysGit and why is it (going to be?) unsupported

Avery Pennarun
On 8/6/08, Petr Baudis <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Potapov
In reply to this post by Petr Baudis
On Wed, Aug 6, 2008 at 3:15 PM, Petr Baudis <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html