Re: [msysGit] Trailing spaces in branchname (git-svn)

> I am trying to clone a subversion repository that has a branchname
> with a trailing space. Since I can't find a solution I downloaded the
> code to try to understand the problem. Since I am not familiar with
> perl it is a bit hard for me. This is what I have found out so far:
>
> In git-svn.perl:
> tmp_index_do is called and tries to create the folder with the
> trailing space (under svn/refs/remotes) with the following line of
> code:
> mkpath([$dir]) unless -d $dir;
> reading the solution above, I figured that I should be able to
> "sanitize" the path -reusing som code already existing in the script:
>        sub refname
> I then tried to:
> git svn fetch
>
> Now the folder gets created, but then some lockfile is supposed to be
> created (with the trailing space in the path), and it fails again.
>
> I have not been able to locate the call that tries to create the
> lockfile (yet), and I guess there will be more fileoperations made to
> the folder. If I manage to figure out the code my theory now is to
> "sanitize" the branchname in the structure where it is contained when
> it comes from subversion (possibly adding a "sanitized" storage to not
> destroy the original name if it is needed), and see if the clone/fetch
> can continue.
>
> My hope is though, that someone who understands this maybe can fix it,
> or maybe point me in the right direction.

>
>> This kind of question is usually better to ask on the main Git mailing
>> list, as it's not really Windows specific.
>
> I found a similar (older) thread in the git-mailing-list, discussing
> the same issue. This led me to try cloning the same repository on a
> Linux-machine - with success. Linux (at least my distro - Ubuntu)
> handles trailing spaces in directory names.
>
> Isn't this a msysgit-issue? (I just want to make sure that I don't
> spend my (and your) time in the wrong place)

> On 15 Juni, 16:00, Erik Faye-Lund <kusmab...@gmail.com> wrote:
>> Please don't cull the CC-list.
>>
>> On Wed, Jun 15, 2011 at 3:38 PM, Barthus <magnus.kallst...@gmail.com> wrote:
>>
>> >> This kind of question is usually better to ask on the main Git mailing
>> >> list, as it's not really Windows specific.
>>
>> > I found a similar (older) thread in the git-mailing-list, discussing
>> > the same issue. This led me to try cloning the same repository on a
>> > Linux-machine - with success. Linux (at least my distro - Ubuntu)
>> > handles trailing spaces in directory names.
>>
>> > Isn't this a msysgit-issue? (I just want to make sure that I don't
>> > spend my (and your) time in the wrong place)
>>
>> If it works on Linux then yes, it's probably a Git for Windows issue.
>>
>> Some quick testing reveals that paths can have a trailing space on
>> Linux, but not on Windows. It sounds to me like you need to modify the
>> refname subroutine in git-svn.perl to escape this. Something like this
>> seems to work for me:
>> ---8<---
>> diff --git a/git-svn.perl b/git-svn.perl
>> index 7849cfc..7a44145 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -2126,6 +2126,9 @@ sub refname {
>>         # @{ becomes %40{
>>         $refname =~ s{\@\{}{%40\{}g;
>>
>> +       # trailing space is not not allowed on Windows
>> +       $refname =~ s{ $}{%20};
>> +
>>         return $refname;
>>  }
>>
>> ---8<---
>> If it works for you, I'll submit a proper patch for it.
>
> Ok, thanks. I'll try as soon as possible (will be away for a few
> days...)
>

> (I hope I get it right now - previously I used Googles web-interface, and I
> just couldn't find a way to respond to all. Trying from my email client
> instead now... I have even read the 'Welcome post' again :) )
>
> Unfortunately, the patch didn't work.
>
> This is the error I get when it aborts:
> Found branch parent: (refs/remotes/CR3533 sökning på fakturabelopp )
> be4dd98d152d82f098b90089f4df6a2d411d84e1
> fatal: Unable to create 'd:/Dev/GIT/svk/KOB/.git/svn/refs/remotes/CR3533
> sökning på fakturabelopp /index.lock': No such file or directory
> read-tree be4dd98d152d82f098b90089f4df6a2d411d84e1: command returned error:
> 128
>
> The patch itself is probably working for other parts, and I even tried a
> similar patch back in March. I never managed to figure out where the call to
> the locking-function got it's path though.
>