1

Say I have Project1 in a git repo. Within Project1 there is a subfolder that I want to include in Project1+ (Project2, Project3, etc.) By "include" I don't mean copy-and-paste. I want a reference to Project1 so that if I make changes to Project1 I can automatically integrate those changes in Projects1+. Further, I want to place it in more than one location within Project1+.

Example:

Project1
|-Subfolder1
  |-Stuff I want...
|-README.md

Project2
|-Subfolder1 <- from Project1
|-SomeOtherFolder
  |-Subfolder1 <- from Project1
|-README.md

Git submodules won't work because:

  • The submoldule is the entire repo, not the subfolder. I don't want the entire repo, just the one folder.

The subtree merge strategy won't work because:

  • Only one subtree is supported; when you do the pull for the subtree (git pull -s subtree...) it only updates the one at the highest level (no matter the order in which they were created).

Now bear in mind I am new to git so it's possible the above conclusions are wrong. But this is what I have discovered through both research and experimentation.

The possible solution I have come up with is:

  1. Create a branch for Project1.
  2. Delete everything I don't want from this branch.
  3. Move the files I DO want to the root of this branch.
  4. Delete Subfolder.
  5. Add this branch as a submodule to Project1+.

This sorta-kinda worked. I modified the Project1 master branch and was able to merge the changes into the new branch, and therefore update the submodule, but this seems unnecessarily complex (given how easy it is in SVN). Furthermore when I merged the changes in Project1 it seemed to consider the deleted files as conflicted; i.e. it was just a huge PITA to update Project1. Maybe I need a different merge strategy?

But mainly I'm asking is this even the right path at all?

For the record, this is trivially easy with SVN Externals. So the use-case is there. And I realize it's entirely possible no one is doing this with git. The explanations I can find online after a couple days of research all boil down to "restructure your projects so each repo has what you want to share"; i.e. "Subfolder" from Project1 becomes its own repo. I'm hoping that's not really the final answer.

Thanks!

Josh
  • 145
  • 1
  • 7
  • SVN tags unrelated to content! Retag? – Lazy Badger Nov 07 '12 at 00:20
  • I don't understand what you mean. The description clearly mentions SVN, specifically to use an SVN feature as an analogy for what I want. Certainly there is a large group of people who use both SVN and git and who have made similar transitions. What tagging would you suggest? – Josh Nov 07 '12 at 01:30
  • your question doesn't correlate with svn. You just **mention** svn-externals, but your task is clearly described without this analogy (svn:external) and **totally Git-centric**. – Lazy Badger Nov 07 '12 at 01:49

1 Answers1

2

Anyway, for all possible workflows you have to use 3 repositories: Subfolder1 becomes separate repo, which you'll use in "superrepos"

  • I think, you can use even submodules (with the note above)
  • IMHO (very humble), git-subtree is better iteration and will be complete replacement of uly submodules in nearest future. Sharing code between projects with git subtree demonstrate nice use-case for situation almost identical to your with detailed step-by-step illustrated with commands guide of converting monolitic repo into linked by subtree 2 repos, there separated repo is ready to re-usage
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • EDIT: never mind, I see what you mean. I have to change the repo layout no matter what, but I should move to subtree instead of submodule. Fair enough. _Correct me if I am wrong, but git subtree appears to add the whole repo. I.e. it's the same as git submodule in the context of this question._ – Josh Nov 07 '12 at 01:47
  • @Josh - yes, whole repo, just because Git (contrary to SVN) can't demonstate subtrees inside repo - it's always monolithic object for the external world (NAME.git) – Lazy Badger Nov 07 '12 at 01:55
  • Small update: Switching to separate repos defeats the purpose of revision control IMHO. It means I have to manually copy files from one repo to another, manually stage the changes, etc. Separate issue: subtree isn't included with the GitHub client on Windows (i.e. it's not part of the base installation of git). According to the author it's in the "contrib" subtree. Looking at the source, I don't think it would work on windows anyway. Too bad, it looks nice. Will reply later with my final solution, still testing. – Josh Nov 13 '12 at 21:01
  • @Josh "Switching to separate repos defeats the purpose of revision control IMHO. It means I have to manually copy files from one repo to another" - no, re-read Psionides text: theere are not dumb file copy between – Lazy Badger Nov 14 '12 at 03:53