1

I'm not sure how to do that with Git: (Module are files or folders)

MyCoreRepo:
Module1
Module2
Module3
Module4

MyCompositeRepo1:
Module2
Module3

MyCompositeRepo2
Module1
Module4

The goal is being able to pick some modules (a kind of composition). MyCompositeRepo1 is picking Module2 and Module3 then some specific code is added and it stays at MyCompositeRepo1 level (not shared with MyCoreRepo).

If I add new functions in Module2 or Module3 in MyCoreRepo, MyCompositeRepo1 should be able to pull it(update its Module2 and Module3) without destroying the specific code that has been added meanwhile.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
François Richard
  • 6,817
  • 10
  • 43
  • 78

1 Answers1

1

If each modules are actual submodule repos, each one grouped in their parent repos, then it is easy to mix and match them.

But considering your "Modules" can even be simple files, this makes submodules not a natural fit.

If you can only deal with folders, then submodule repos make sense, and MyCompositeRepo1 will be able to update its submodules (track the latest from a branch) with:

git submodule update --remote

without destroying the specific code that has been added meanwhile.

As long as that code is added in its own specific branch, said branch can be rebased on top of what has just been fetched (or you can merge what you just fetch to that branch).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Dumb question: If I have 50 differents modules/files I would have to create 50repos ? isn't it a little bit annoying ? is there any way to do the same thing but within the same repo ? (being able to pick things in the same repo) thanks for your answer already – François Richard Jul 26 '16 at 05:06
  • Actually I was thinking using sparse checkout , it seems you are a real Git expert , what do you think ? Would sparse checkout be adapted to my usecase ? – François Richard Jul 26 '16 at 05:42
  • @FrançoisRichard For 50 "modules", that would be 50 repos, yes. The main advantage is those 50 repos have their own history, tags, branches. The alternative approach is subtree, with it is less a good fit for composition: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ – VonC Jul 26 '16 at 06:17
  • @FrançoisRichard Sparse checkout works when you have one main repo. In your case, you have several main repos (core, composite1, composite2,...): in that case, you cannot sparse checkout one repo within all 3. – VonC Jul 26 '16 at 06:18
  • @FrançoisRichard As usual with this kind of issue, you need to make sure you are not describing an X Y problem (http://meta.stackexchange.com/q/66377/6309): ie describing an implementation of a solution (here using composition) rather than the actual problem (why do you need to pick "modules" or even just files from another repo? Is there any alternate approach that should be considered) – VonC Jul 26 '16 at 06:21
  • Composition1 is a composition of things picked in main core only that's why the sparse checkout may work – François Richard Jul 26 '16 at 06:44
  • You're right I rather ask about my need s instead of directly asking about a specific implementation. We are building several backbone small apps a lot of code can be shared for example similar views but just pulling the whole main core makes you clean every unused view or module that's why I would like to be able to pick only what I want when I start a new declinaison of the app. Hope it's clearer – François Richard Jul 26 '16 at 06:48
  • @FrançoisRichard With Git alone, submodule is good for sharing "the main core" (that is *one* folder). For all the other files, it is best if they can be generated from a template rather than cherry-picked. – VonC Jul 26 '16 at 06:54
  • But for the views, lets say I have topbarView, sidebarView, footerView in a specific "repo view", and for my project I just want topbarView and sidebarView, is it really a bad idea to use sparse checkout those and combine it with maincore submodule ? (is it even possible ?) thanks again for all the time you took to share your knowledge – François Richard Jul 26 '16 at 07:23
  • @FrançoisRichard it would be trying to use Git in a way which is not natural at all. It is easier to think in term of all repo. Again, in a separate branch, you can trim those files to the exact ones you need. But not in a separate repo. – VonC Jul 26 '16 at 07:57
  • so you suggest I have a kind of branch "masterCore" and I create branches for each project ? – François Richard Jul 26 '16 at 08:15
  • @FrançoisRichard Yes, but you can have multiple clones of your main repo, each one with the appropriate branch. – VonC Jul 26 '16 at 08:17