5

I'm trying to transition my cvs repository to git and have been stuck on this last issue for a while.

I currently use CVS ampersand modules to share code between projets. Those allow you to basically "alias" a different repository as a subdirectory in your project, so you can update / commit the whole project and it's included remote repositories as if it was one repository.

I've seen threads that recommend subtree merges or submodules for doing this, in reference to (svn:externals). This won't work because:

  • subtree merges apparently don't allow you to easily push back / update the external repos.

  • submodules still require you to manually push / pull every submodule. I have a large number of submodules and going into every single one to push my changes would be tedious and could lead to omissions as changes would forget to be committed.

Just to be clear, I would like to have a git repository that contains other git repositories as subdirectories, and be able to commit / push / pull to all of them at the same time with one command.

Dale Hagglund
  • 16,074
  • 4
  • 30
  • 37
paulsc
  • 51
  • 1
  • 2
    Submodules are on their way to becoming a little bit closer to what you want - `git fetch` is now submodule-aware, and I'm sure more will come. Committing in submodules is a little farther from their intended purpose, though. – Cascabel Jan 18 '11 at 21:09
  • 1
    It seems you are right, submodules are what I'm looking for, but they are not quite there yet. I'm surprised though as I felt this workflow is fairly common and git has been around for a little while now. – paulsc Jan 18 '11 at 22:08
  • 1
    @paulsc: I think something slightly different is more common: working on the subproject independently of the superproject, then now and then updating the superproject to a newer version of the subproject. – Cascabel Jan 18 '11 at 22:27
  • Oh, and a related question: [the only one I've ever asked](http://stackoverflow.com/questions/3712917/highly-coupled-git-submodules). – Cascabel Jan 18 '11 at 22:33
  • Yes that's exactly what it is. The modules are highly coupled, and thus I make a lot of changes in all modules at the same time, and need to be able to push / pull the changes easily. – paulsc Jan 24 '11 at 17:10
  • @paulsc: Are they highly coupled to each other, or to some common interface? If to each other, you should consider treating them as one porject. – wnoise Feb 06 '11 at 08:56

3 Answers3

1

That's very much un-git. If they are separate projects, they belong in separate repositories.

However, the repo tool is used by projects such as Android to provide a layer above git that encompasses a large number of dependent projects which may come from different locations and allows you to have a workflow from local branching of all of them through revision control (which may go to different locations by project).

It's a layer up and if you're expecting the exact git experience, you'll not get that. You can use your standard git tools in any subproject, but at the top level, you're using a different tool for the coordination.

Dustin
  • 89,080
  • 21
  • 111
  • 133
  • It seems like our workflow wouldn't be that uncommon, which is why I'm confused as to how other people deal with this. They are separate projects, but that share a substantial amount of code. So each project is subdivided into 'components' that would ideally be mapped to one git repository per component. The need to commit things atomically (i.e. multiple components / git repos at once) stems from not wanting to miss any of the changes to any of the different components. – paulsc Jan 18 '11 at 22:01
  • Also repo seems interesting - athough specific to android right now. It seems that the way to accomplish this workflow now it to just roll your own on top of git. – paulsc Jan 18 '11 at 22:09
  • It's not specific to Android. I'm using it in another project now. The projects are separate and the container itself can tie together related versions on different branches. If you don't do this, you're going to run into trouble when two projects introduce conflicting changes to their shared project. – Dustin Jan 18 '11 at 22:33
0

If I understood your question correctly, then you need git submodules.

ulidtko
  • 14,740
  • 10
  • 56
  • 88
0

My git-subtree project makes it possible to re-extract changes after doing a subtree merge. Many people find this to be the best of both worlds between git-submodule and subtree merges.

apenwarr
  • 10,838
  • 6
  • 47
  • 58