It's possible with git submodules to checkout multiple repositories as submodules into respective paths, e.g.:
% git submodule add git#.../repo1.git ./here/is/1
% git submodule add git#.../repo2.git ./here/is/2
But what if I need to checkout the contents of repo1 and repo2 both into a single path, ./here/is/3?
Basically I have a metric shit-ton of submodule repos I need to all be checked out into a very rigid directory hierarchy on the client side when the user does git clone --recursive ...
I want the contents of all submodules to be checked out into ./somepath. Can it be done?
One thing I considered was using symlinks, but that feels wrong.
EDIT:
I want the contents of 1 and 2 in the above to be placed in the same target directory on the client. I can do this by having the user manually run a script after cloning (it is not possible to have git track a single file), but it seems like there should be a cleaner way to do this -- manually creating a symlink for each submodule is a lot of work, and it seems like the submodule abstraction should be able to handle this.
Maybe my question is a dupe-in-disguise?
One way would be to create another parent repo, with the submodules declared directly in it:
newParentRepo/
1/
2/
3/
...
That parent repo could be cloned --recursive in ./somepath, and the submodules would be directly under ./somepath (in their respective root directories 1/, 2/, ...).
You would need to synchronize the SHA1 of the submodules as recorded by the first parent repo into the second parent repo, in order for said second repo to record the right list of submodules SHA1.
Related
My project uses svn and I went git along time ago. I've been using git-svn for quite a while with a lot of success. But now at a new employeer, I'm having some problems.
The layout in SVN is:
http://path/to
/trunk/
submodule1
submodule2
/branches/
branch1
submodule1
branch2
submodule1
submodule2
I checked-out my git-svn to track each submodule (which I think is the right way to go).
git svn clone http://path/to/trunk/submodule1
git svn clone http://path/to/trunk/submodule2
Which gives me trunk, but I can't figure out how to track each branch. I want to think that --prefix would help me, I don't think that it will.
Anyone have ideas?
You should be able to achieve this using wildcards in your layout specification. I.e. for submodule1 you would do
git svn clone --trunk=trunk/submodule1
--branches=branches/*/submodule1 \
--tags=tags/*/submodule1 \
http://path/to
(assuming you also had tags following the same pattern). Repeat the same for the other submodules.
The --prefix option has nothing to do with this. It just controls how the branches will be named in the resultin git repository. Without the option, all branches will go straight under refs/remotes/. If you'd like something more like the usual remote branch layout, you can use e.g.
git svn clone --prefix=svn/ ...
to get refs/remotes/svn/trunk, refs/remotes/svn/branch1 etc. The value is prepended verbatim to the resulting branch names, so you need the trailing / or you'll end up with something like refs/remotes/svntrunk
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.
I am trying to use git svn to connect to our company repository. We have a slightly non-standard branches directory. How to access this using git svn has been discussed before, however, we seem to have a slight twist in our branch names that seems to keep me from getting them all.
Let's consider an example svn repo:
trunk/
tags/
branches/
rootbranch/
tku/subbranch
We have branches at the root level of the branches directory. But we have branches in nested folders, as well. The same goes for the tags dir, but I think that is just a second example of the same problem.
If I use git svn clone file:///tmp/gitsvn/svnrepo git-clone -s, I get only the root branches, as expected:
/tmp/gitsvn/git-clone$ git branch -r
rootbranch
tku
trunk
But if I clone using _git svn clone file:///tmp/gitsvn/svnrepo git-clone2 -b branches//_, I get only the sub-branches:
/tmp/gitsvn/git-clone2$ git branch -r
tku/subbranch
Is there a way to have both?
Additional branches can be accessed by adding multiple branches lines to the git-svn config.
In the .git/config file, there will be a section similar to the following:
[svn-remote "svn"]
url = http://server/svn
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/branches/*
tags = tags/*:refs/remotes/tags/*
Simply add another entry for the extra directory of branches. For example:
branches = branches/tku/*:refs/remotes/branches/tku/*
Then run git svn fetch to retrieve the branches from the svn repository.
I believe it's also possible to create this setup when constructing the git repository, using multiple -b options to the clone command.
git svn clone http://svn.foo.org/project -T trunk -b branches -b branches/tku -t tags
For anyone else who stumbles over this: it seems that having both is not possible. Subversion allows a mixed setup of branches, but it is discouraged, and so it seems okay that git does not support this. My solution was to bring all branches to the same level, then forget about the issue and move on. Having only one level of branches seems better anyway.
I'm getting a hang of git submodule (wishful thinking?) and I'm coming up with more specific questions, which is a good sign...
I've tried to find the which revision of the submodule the superproject refers to, in .gitmodules and .git/config, but nothing is mentioned there...
The scenario is that I'm changing submodules in their root locations (from which they're imported), and then pulling them in where they're "submoduled"...
Beyond committing from the superproject to incorporate those changes into the superproject repo, do I also need to do "git update" to register the new pulled in submodule commits?
Basically the question is:
do I need to "git submodule update" only when I first clone the superproject, or after every pulling of the submodule (from its own repo)?
Thank you
As mentioned in my previous answer to git submodule update, that command checks out the specific version of the project, base on their .gitmodules file.
The GitPro page does insist:
This is an important point with submodules: you record them as the exact commit they’re at.
You can see which commit is referenced by running within the "super project" (the one referencing one or several submodules):
git submodule status (except if you did some commit directly within that submodule, in that case it will show a "+" in front of the SHA-1 of the HEAD of any submodule that has advanced from the SHA-1 stored in the superproject) or
git ls-files --stage looking for entry in mode "160000", a special entry in the Git index.
That means, each time you execute a git command in the "super project" which could modify that submodule commit SHA1, you need a "git submodule update".
do I need to "git submodule update" only when I first clone the superproject, or after every pulling of the submodule (from its own repo)?
Yes, you have to do this every time you pull down a submodule change in the main project.
That is because you are referencing the exact commit the submodule original repo is at (as said above), and when you pull that repo, you are effectively modifying that commit.
I'm coding a framework along with a project which uses this framework. The project is a Bazaar repository, with the framework in a subfolder below the project.
I want to give the framework a Bazaar repository of its own. How do I do it?
You use the split command:
bzr split sub_folder
This creates an independant tree in the subfolder, which you can now export and work on separately.
Use fast-import plugin (http://bazaar-vcs.org/BzrFastImport):
1) Export all your history to the stream:
bzr fast-export BRANCH > full-history.fi
2) Filter the history to produce new stream:
bzr fast-import-filter -i subfolder full-history.fi > subfolder.fi
3) Recreate new branch with subfolder only:
bzr init-repo .
bzr fast-import subfolder.fi
As far as I know, there is not a way to do this easily with bazaar. One possibility is to take the original project, branch it, and then remove everything unrelated to the framework. You can then move the files in the subdir to the main dir. It's quite a chore, but it is possible to preserve the history.
you will end up with something like:
branch project:
.. other files..
framework/a.file
framework/b.file
framework/c.file
branch framework:
a.file
b.file
c.file
As far as I know, "nested" branches are not support by Bazaar yet. Git supports "submodules", which behave similar to Subversion externals.
I have tried doing this with bzr split, however, this does not work how I expect.
The resulting branch still contains the history of all files from all original directories, and a full checkout retrieves all the files. It appears the only thing that split does is convert the repository to a rich root repository so that this particular tree can be of a certain subdirectory only, but the repository still contains all other directories and other checkouts can still retrieve the whole tree.
I used the method in jamuraa's answer above, and this was much better for me as I didn't have to mess with converting to a new repository type. It also meant that full checkouts/branching from that repository only recreated the files I wanted to.
However, it still had the downside that the repository stored the history of all those 'deleted' files, which meant that it took up more space than necessary (and could be a privacy issue if you don't want people to be able to see older revisions of those 'other' directories).
So, more advice on chopping a Bazaar branch down to only one of its subdirectories while permanently removing history of everything else would be appreciated.
Do a
bzr init .
bzr add .
bzr commit
in the framework directory.
Then you can branch and merge to just that directory.
The bazaar higher up will ignore that directory until you do a join.
Bazaar understands when you do things like
bzr branch . mycopy
bzr branch . myothercopy
The current directories .bzr won't track those subdirectories changes.
It saves you from trying to find a place to put a branch.