git svn clone can't deal with spaces in tags/branches #180
Comments
|
@dannce please try to come up with a Minimal, Complete, and Verifiable example. |
|
@dannce hint: you can initialize a Subversion repository in the file system and zip it. |
|
@dannce any progress? Or is this ticket no longer relevant? |
|
I'm sorry, but I don't work with SVN myself and have this version of Git no longer installed. But any branch of the form "branch name" can't be copied and the "git svn clone"-command will terminate. |
|
I can not reproduce this behavior, seems to work fine: cd /usr/src
mkdir test && cd test
svn init a
svn co file:///usr/src/test/a b
cd b
mkdir trunk
svn add trunk
svn commit -m"initial"
cd ..
svn copy file:///usr/src/test/a/trunk "file:///usr/src/test/a/space adventure" -m"making a space adventure"
git svn clone file:///usr/src/test/a c
cd c
git log
|
|
I don't know SVN, but it doens't look like to me that you've created a branch or tag, only a file with a space in its name. Nevertheless, I think this issue can be closed: I can't reproduce the bug in using git version: Git-2.4.4.2-3rd-release-candidate-64-bit. This version can clone SVN branches with spaces in it just fine. The version I used when making the bug report was: Git-2.4.1.1-dev-preview-64-bit. Ps. Here is a thread that discusses this whitespace problem in branches/tags: |
|
http://stackoverflow.com/a/13083877 indicates that too. |
…reamable version I'm creating this PR for a fourth time (see git-for-windows#163, git-for-windows#171, and git-for-windows#178 for earlier versions). This version is tracking my progress to create something that can be sent as an RFC upstream, but also can be used to start the sparse feature branch. This is based on v2.23.0. Note: I currently have conflicts with the virtual filesystem feature, and I'll resolve those with a merge commit when I'm ready. I'm just creating this for tracking progress at the moment, but can also be a place for early feedback. * git sparse-checkout disable to disable the sparse-checkout feature and return to a full checkout. * git sparse-checkout init --cone, to initialize in cone mode. * git sparse-checkout add when core.sparseCheckout=cone. This includes performance improvements with the hashset-based matching algorithm, but I'll leave further enhancements as smaller steps on top. Here are a few things I want to try: Track the maximum depth of a prefix pattern, so we know to not run hashes for deeper paths. Use the "known exclude" bit in cone mode to stop hashing paths we know will not be included. Use the "known include" bit in cone mode to stop hashing paths we know will be included. This is more difficult than "known exclude" because we need to distinguish directories from files when doing path matches so we don't give a directory a "known include" when it isn't a recursive pattern match.
In git-for-windows#183, I reverted a change to builtin/checkout.c that slowed down 'git checkout -b'. That change introduced a new instance of the core_apply_sparse_checkout global value that was not in the previous version. I then merged git-for-windows#180 without regenerating a build. My bad. This fixes that remaining core_apply_sparse_checkout instance. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
… constant In git-for-windows#183, I reverted a change to builtin/checkout.c that slowed down 'git checkout -b'. That change introduced a new instance of the core_apply_sparse_checkout global value that was not in the previous version. I then merged git-for-windows#180 without regenerating a build. My bad. This fixes that remaining core_apply_sparse_checkout instance.
When trying to clone a SVN repository that has spaces in a branch, I get an error. Note that in git 1.9.5 for windows (and I've heard that in the latest git for *nix systems) this command works.
The text was updated successfully, but these errors were encountered: