Jump to content

git fast-export filename encoding not handled correctly


Recommended Posts



I'd like to bring up the encoding issue for unicode filenames again. I've already posted on StackOverflow (see http://stackoverflow.com/questions/30366389/plasticscm-fast-import-octal-escaped-file-names-when-importing-from-git-svn), however, I think this forum is the better place for follow ups.


I am referring to these posts: http://www.plasticscm.net/index.php?/topic/930-importing-tfs-project-into-plastic/page-2 and http://www.plasticscm.net/index.php?/topic/618-fast-export-failing-to-deal-with-non-english-chars-in-branch-names/page-2

There are scripts mentioned, though not provided, claiming to reencode the octal encoding of file names within the git fast export file. Since I'm not that perl-expert I don't have a clue how to script this reencoding. Provided scripts just handle quotes. Using them wasn't any help; in fact I wasn't able to import the scripted export into Plastic SCM at all (so I'll stick with unmodified quotes).


I think Plastic should simply handle the format that git provides since it claims that fast import is the one and only way to bring the history of foreign version control systems into Plastic SCM. Porting our history is quite an important point in our evaluation plan.


Any help would be appreciated.


Best regards


Link to comment
Share on other sites

Hello Jan,


do you have any idea of the symbol causing the failure?

Is it possible for you and your company to share a "NO DATA" fast-export package so we can diagnose it internally?


Did you tried gitSync instead of a fast-export package? It's worth to try since gitSync avoids writing the data info files.

Link to comment
Share on other sites

I've sent you some information. I hope they help you to dig deeper.


Meanwhile, I was trying to setup an git server hosted on IIS/Bonobo. Took me some time. Now I want to push our sources to it and IIS is choking because of large requests over https. Git is proving not to scale very well every time I get in touch with it.... My reason for trying Plastic. :)


Reason for all this IIS overhead was to provide a server to Plastic to be able to sync with. As far as I can see, Plastic supports protocolls http(s), git, and ssh. I'd like to sync it simply with file:// but I don't manage to set up the sync using this protocoll. Is there any way to sync plastic with my local git repo easily?

Link to comment
Share on other sites

I've just finished importing a subset of our SVN revision through a git sync. Result was as expected. :) The umlaute are coded correctly.

The workflow I've used is even better, since I now have a bridge from SVN through git to PSCM which can transport changes after the migration.


There is one flow left: For the import, I have to provide either GIT, HTTP(s), or SSH protocoll. Git and HTTP protocoll lack security (especially git), HTTPS doesn't work out of the box for me (IIS), same for SSH (cygwin). It would be very convenient, if I could just connect trough file://

Currently, I have to run the git deamon behind a router / in a VM in order to hide it from our network. (Our protocols require that our repo is not visible to the intranet unprotected).

Link to comment
Share on other sites

Happy to know GitSync is working fine! :) 


As I told you we don't need to write the files to disk so it's much more better. And as you said it allows you to bridge the two systems to carry on with the migration (it's also doable with the fast-export/import but a little bit tricky).


Regarding security, SSH and HTTPS should work fine (tested with bitbucket & github). Can you share your setup by email? We'll take it a look down here.

Link to comment
Share on other sites

I have tried bonobo git server on an IIS, in order to have https support. I have created root certificate, cert for https, trusted connection, etc.

My https issues are basically those in this thread complaining about size limitations when pushing into the repo:



I was able to alter some configurations of bonobo and IIS, however problems persist (in a different manner, though). After one day digging into this topic I felt like giving up to try avoiding git scaling issues with this protocoll.


SSH on cygwin didn't work out at all because I didn't manage to setup a working ssh server on the machine. I was considering setting up a debian VM for native ssh support by OS, but since I have my bridge now, I focus on PSCM evaluation instead.


For now, git in a VM (i.e. behind NAT Router) works fine for me. However, with local file:// protocoll I could move to a real machine with better performance. This is a matter for actual first migration.

Link to comment
Share on other sites

I've got a problem syncing into the git repo.

My repo is published with git deamon:

git daemon --export-all --base-path=. --reuseaddr --enable=receive-pack

I made a test commit within Plastic SCM. I am trying to sync this commit into git. I select the main branch (I only have this one) => Replication => Sync with git...

The sync completes successfully within Plastic SCM. However, the git deamon complains with this error: [2240] fatal: The remote end hung up unexpectedly
git log doesn't reveal any new versions within the git repo.

I am running git 2.1.4 within cygwin and PSCM

Link to comment
Share on other sites



I don't see how the links could help me as they consider http buffer settings, but I am using the git protocol.


I've activated the verbose flag on the git daemon which gives me following information:


[900] Ready to rumble
[816] Connection from [::1]:49186
[816] Extended attributes (16 bytes) exist <host=localhost>
[816] Request upload-pack for '/MyRepo'
[816] fatal: The remote end hung up unexpectedly
[900] [816] Disconnected (with error)
[1712] Connection from [::1]:49187
[1712] Extended attributes (16 bytes) exist <host=localhost>
[1712] Request receive-pack for '/MyRepo'
[900] [1712] Disconnected


This is how I start the daemon:

git daemon --verbose --export-all --base-path=. --enable=receive-pack --informative-errors


I am trying to push a very small change (two lines in one source file).




Link to comment
Share on other sites



- I figured out what´s happening. Actually you can ignore the error message because the Plastic changeset is being pushed correctly. But the problem is: you are using a git non-bare repository (http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html). You have git repository with a working worky. According with the git non-bare behavior, if you have a working copy updated in master branch and you perform a pull to get the commits from a different server, the branch reference is not automatically updated.


- You can create a task branch in Plastic and push it to git. You will see that it´s correctly being imported.


- How to fix and update the reference if you are working in master in git and you are pushing changes to master from Palstic:


     1)  Open the:  "C:\Users\xxx\AppData\Local\plastic4\sync\git\302a6c51-8cf2-40ca-979a-de2a54437d3b\case.mapping" file.  This file, maps the different Plastic changesets - git commits.  Annotate the last commit of the branch.

     2)  Change the master branch reference to point to the last imported changeset. Edit the  "gitRepo\.git\refs\heads\master" file, replacing the commit value by the value gotten from "case.mapping".



If you have anu question, please don´t hesitate to ask.




Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...