views:

42

answers:

2

Project layout:

/project_a
   /shared
/project_b
   /shared
/shared

project_a and project_b both need to contain the shared folder. With svn, we used svn:externalsand that worked fine, since svn can reference subdirs (with relative paths too). However, we moved to git and it seems to not support checking out subdirs.

Our solution now is to put project_a, project_b and shared all in different git repos, and use git submodules in project_a and project_b. However this seems much more complicated than one monolithic svn repo with svn:externals. What's the correct way to handle common elements in git?

EDIT: The consensus is submodules are the way to go. But having used it for a day, it seems very unfriendly to use.

After making a change to a file in shared, I have to:

  1. Commit the change in shared
  2. Push the change in share
  3. Add the shared directory again in the parent directory
  4. Push the parent directory

Compared to a single commit in svn, this seems way more complicated. And missing one of these steps results in a huge versioning mess. Am I missing something here?

A: 

I think thats the way to go with git. :) (not really an answer, but still).

reto
+1  A: 

Submodules are the right answer.

The fact that you don't conserve the monolithic approach of SVN is pretty much by design with a DVCS (where you tag and reference a repository as a all).

That allows you to reference an exact configuration (see submodules true nature), that is you will always refer to an precise SHA1 reference (as opposed to svn external, where you rae not obliged to indicate a revision number).

VonC
Thanks for the detailed answer VonC. Having to run 4 steps is a dealbreaker for us, back to svn it is
phillee