I am working with subgit and I don't understand well how it deals with svn externals. I found this in the help
[translate]
externals = [true|false]
a boolean value, can be set to true or false. SubGit does not support translating svn:externals to Git submodules and back. However,
when this option is set to true, SubGit creates special
.gitsvnextmodules files in the root of every Git commit; these files
store information on all the svn:externals definitions found in a
given SVN branch. When false, SubGit ignores any svn:externals
properties. Default is false.
Does this mean that the externals are not processed at all but just logged into a file so that you are aware of?
Could I create a hook with subgit to the external repo and make that new git repo as a sub-module for git ?
THanks in advance,
That's right, SubGit doesn't create neither submodules, nor subtrees out of SVN externals. If svn.externals is set to 'true', then SubGit indeed just logs the SVN externals definitions to .gitsvnextmodules file and nothing more.
Probably it's possible to create a script that would create submodules, but I'm not aware or ready solutions for that and there's no such feature in SubGit.
Related
I would like to follow a SVN-Repo via git-svn, that has a restriction on it's root node.
Precisely that is:
* SVN with standard layout (trunk, branches, tags)
* anonymous read access on the above directories
* no read access on the root dir
The classic approach with "git svn clone -s ..." doesn't work here, because it requires read access on the root node.
Is there any possibility to circumvent this?
The goal for a solution would be to follow trunk, branches and tags within a common git repository.
I should have read the entire git-svn manual... ;)
git svn init has this additional option:
--no-minimize-url
When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect to the
root (or highest allowed level) of the Subversion repository. This default allows better tracking of history if entire
projects are moved within a repository, but may cause issues on repositories where read access restrictions are in place.
Passing --no-minimize-url will allow git svn to accept URLs as-is without attempting to connect to a higher level directory.
This option is off by default when only one URL/branch is tracked (it would do little good).
That'll do it.
I need to switch from Composer (which is used by Symfony2 by default) to Git submodules.
I thought I could just add the desired submodules to the desired locations, thus overwriting the current version which was installed by Composer.
But when I use git submodule add, it says:
'vendor/twig/twig' already exists in the index
So I tried:
git rm vendor/twig/twig
and tried to add the submodule again, same error.
What am I doing wrong?
I'm founder and ceo of cloudControl. Currently composer does break our image building process because it interferes with the logic we have to detect submodules in some way. The team is aware of this problem and working to fix the underlying issue.
I'm working for cloudControl and we've been lately inquiring into this issue.
Regarding the original problem, you proposed already a right solution for replacing the composer packages by git submodules, it was just a git commands issue. But doing this doesn't make much sense, as long as these git submodules are identical to the Composer packages and your php code is still hanging on the autoload.php provided by Composer.
We don't process internally Composer yet, their files are just added into the repository and the php code requirements make the rest. However we do process git submodules, so if you want to make a real switch from Composer to Git Submodules, the best option is getting rid of Composer files (vendor folder and composer.* files), adding git submodules wherever you want and handling again the php dependencies . Thus everything should work fine and you'd have switched completely to git submodules.
Native support for Composer is in our future plans.
The problem was that i had to actually delete and git-remove the repository first.
i.e. for twig what i did in the end was:
git rm -r vendor/twig/*
rm -r vendor/twig/*
git add vendor/.
git submodule add git://github.com/fabpot/Twig.git vendor/twig/twig
git submodule add https://github.com/fabpot/Twig-extensions.git vendor/twig/extensions
Now i have twig and twig extensions as a git submodule and can use it in my cloud application.
If I tell git to ignore x amount of files and never add them to the repository, will those files also make it into the svn:ignore property? And if so, how can I keep .gitignore local to only my local git repository?
EDIT Sorry about the duplicate, I searched on here and couldn't find anything on it.
No, git will not do anything with svn:ignore.
From the documentation:
We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn//unhandled.log
Also this other StackOverflow question is very similar.
If you want the .gitignore local to your repo, don't commit it.
Similar question:
How can you indicate files to ignore in svn when using git and the git-svn bridge
git-svn does neither .gitignore — svn:ignore, nor git attributes — svn properties conversion.
You may consider using SubGit instead. It does properly handle ignore, properties, merge-tracking data, etc. Among other things it works on a server-side, so one can use any Git client available to send changes to Subversion repository.
See documentation and comparison with git-svn.
so yeah just wondering if darcs has anything equivalent to git's submodules.
i.e. lets say I have a repo (myapp) and I have a folder in it called mylibrary. mylibrary doesn't really have anything to do with myapp's development, it just has to be included. mylibrary's development happens in it's own repo, but when someone pulls myapp, it'll also pull an up-to-date version of mylibrary. any ideas?
My first thought: Since darcs is simpler than git (i.e., no branches and remotes--instead you just use directories and URLs, and it's your task to manage them), a darcs submodule would not give much more than what you can achieve with standard things like subdirectories or files inside you darcs repo.
If you needed a submodule in order to fix a certain state of the source of the used library, you could perhaps simply put a copy of the library's repo as a subdir and add it to your project's darcs. Compared to git, this would have the disadvantage of bloating the data transfer when someone gets your repo.
If you needed a submodule to tell those who get your repo where to get the updated source of the library (without bloating the size of your repo), you could simply put an URL and an instruction into a README file, or a script, or whatever. Compared to git, the disadvantage is that the state of the library's source as it was when you used it wouldn't be recorded in your commit, so people might get another version of the library, and the compilation wouldn't succeed, and it wouldn't be clear why.
So, the really interesting goal of a submodule could be not just to tell people where to get the library source from (as you write in the question), but to record the state of the subproject that you have actually used for compiling your project, and not to bloat your repo for those who don't want to get the source of the subproject.
Probably, this goal could also be achieved by storing more complex metadata about the state of the subproject, and a more complex hook to get exactly that state (or--by choice--another state) of the subproject. AFAIK from the docs, there is no built-in mechanism for such submodules.
Update (found on the darcs site):
http://darcs.net/Ideas/Subrepositories;
http://darcs.net/Ideas/NestedRepositories.
So, darcs will notice another darcs repo inside your working and it won't touch it. So the first way I've suggested above is shut (if you leave the darcs metadata there).
The second way is like something suggested in one of the section of the latter link. (They suggest an "uglu" script for something like this.)
Another (3rd) idea
Import the patches from the repo you intend to have as a submodule, but first move all files into a subdir. If it were possible just to apply such a moving special patch once and if it was effective for all the patches you import from the repo intended as submodule, but not to the patches you import from a "branch" of the main repo...
...well, it could be a special variant of the pull command (say, import) and of the push command (say, export) that would additionaly translate the paths accordingly.
I don't know of any submodule concept for darcs, which means the usual way to refer to another (shared) repo from a darcs repo would be through symlinks.
Since symlinks aren't supported with darcs, that means you needs to put in place a "posthook sh update-symlinks.sh" hook script to restore those links.
But you could also use add to this hook a check to see first what version of the lined repo is currently loaded, and update that version if needed (provided you have store in one way or another the exact version you need for that shared repo).
That last suggestion is actually close to the implementation of Git submodules or Mercurial subrepos.
Is there any way to use git-svn to clone only some folders of an SVN repo structure. I'm trying to clone a repo that has some crazy big binary files and a number of subfolders that are just plain useless. I've tried using the --ignore-paths option, but my clone seemed to just stall out doing nothing for an extremely long time. Have any of you managed to make --ignore-paths work? I can't find much on the webs where anyone else is running into this. Maybe I'm the only one.
We've used the "ignore-paths" feature to ignore certain directories in a svn repo:
[svn-remote "svn"]
ignore-paths = ^(((branches|tags)/[^/]+|trunk)|)(huge/|mobile/)
This config ignores the "huge" and "mobile" subdirs of the repository in trunk, all branches and all tags.
Perhaps you can illustrate the structure of your Subversion repository to make it easier for us to suggest some solutions.
Are you trying to git svn clone the entire repository from the root-url? Have you tried cloning smaller parts of the repo, and then perhaps grafting several clones together?
The most success I've had here is to manually create branches in git that mirror the SVN remote repository when necessary. The process has been the following:
Update .git/config file with:
[svn-remote "svn-branch-alias"]
url = http://svn/branches/crazybranchname/craziername/url/
fetch = :refs/remotes/git-branch-name
From the command line type: git svn fetch 'svn-branch-alias' to collect the SVN branch data into your local git repo.
Then type: git checkout 'git-branch-name' to go into a headless mode.
Finally type: git checkout 'my-local-git-branch-name' to create move head to the latest submission in that branch and create a local branch alias you can use.
You can now commit and dcommit as usual and still switch between various local git branches and your manually created SVN mirrors using the usual mechanisms.