2

I have a number of client projects, each of which has it's own repo. Let's call them Repos 1-3.

Each client project shares the same base framework/template. Let's call it Repo A. I want every client repo to be able to pull the latest changes from Repo A.

I then have a number of features which I have set up as separate repos. Let's call them Repos i-iii. I want every client repo to be able to pull the latest changes from Repo i, ii or iii, depending on which features the client project has.

Example:

  • Client Repo 1 would pull from Repo A and also say Repo i and iii
  • Client Repo 2 would pull from Repo A and Repo ii
  • Client Repo 3 would pull from Repo A, Repo ii and iii

The client projects never need to push back up to any of the repos "feeding them" but I obviously want to be able to create branches on my client project repos so that I can build, test, merge, etc.

With some help from a somewhat-more-git-experienced friend I currently have the following workflow, which works - to an extent.

After setting up a new client repo, I run the following:

  1. git remote add template [Repo A location]
  2. git remote add [feature repo name] [feature repo location]
  3. git checkout –b [project branch name]
  4. git pull template master --allow-unrelated-histories
  5. git pull [feature repo name] master --allow-unrelated-histories (do this for each feature included in this client project)

Using this workflow I am able to:

  • keep my base template, features and client projects all separate which is nice from a development perspective
  • keep my client projects up to date with the base template and features by periodically running commands 4 and 5 from the list above

Obviously though, I end up with a combined history which isn't ideal.

Is there a better way of doing this?

Important additional info: The repos share folder structure, i.e. I can't contain Repo A in its own folder and each feature repo in its own folder, etc.

Example:

Repo A (Template)       Repo 1 (Client Proj.)   Repo i (Feature)
|                       |                       |
+-- dir 1               +-- dir 1               +-- dir 1
|   |                   |   |                   |   |
|   +-- dir 1a          |   dir 1a              |   +-- dir 1a
|   |   |               |   |                   |       .
|   |   +-- dir 1ai     |   +-- dir 1ai         |       .
|   |       |           |   |   |               |       .
|   |       +-- file a  |   |   +-- file a      |       +-- dir 1aii
|   |       +-- file b  |   |   +-- file b      |           |
|   |                   |   |   +-- file c      |           +-- file x
|   |                   |   |                   |
|   +-- dir 1b          |   +-- dir 1b          |
|       |               |       |               |
|       +-- file m      |       +-- file m      |
|       +-- file n      |       +-- file n      |
|                       |       +-- file o      |
|                       |                       |
+-- dir 2               +-- dir 2               +-- dir 2
    |                       |                       |       
    +-- dir 2a              +-- dir 2a              +-- dir 2a
    |   |                   |   |                   |   |
    |   +-- file t          |   +-- file t          |   + file u
    |                       |   +-- file u          |
    |                       |   +-- file v          |
    |                       |                       |
    +-- dir 2b              +-- dir 2b              +-- dir 2b
        |                       |                       |
        +-- file p              +-- file p              +-- file r
        +-- file q              +-- file q
                                +-- file r
                                +-- file s

I believe this rules out Git Submodules, but thank you @ElpieKay for the suggestion.

Luke
  • 4,825
  • 2
  • 30
  • 37
  • About the folder structure, could you please give an example? If the folders of different repos are decoupled, git submodules could be an option. Another option is Google's `repo`, https://github.com/aosp-mirror/tools_repo. It's a bit complicated but quite good at managing a group of repositories. – ElpieKay Oct 20 '20 at 02:58
  • @ElpieKay thanks and good call - I had thought to try to add an folder/file map but wasn't sure if it would help or confuse. I've ammended my question to illustrate. The actual file structures are more complex than this. By de-coupling, I assume you're referring to containing everything to do with Repo A in its own folder, etc? – Luke Oct 20 '20 at 04:17
  • This is an "I'm going to shoot myself in the face, how do I minimize the damage?" question. Don't break submodules is the only answer I'm willing to spend any time on. Submodules are the better way you asked for. – jthill Nov 04 '20 at 21:51
  • @jthill thanks for that input. So am I to deduce that git is simply not the right tool for the job in my case? I have zero control over the folder/file structure - if I did I'd be putting separate features in separate folders and git submodules would do be an appropriate solution. – Luke Nov 04 '20 at 21:54
  • There's a vcs that cleanly handles a swamp? Multiple, overlapping, independently-updated histories in a single directory? Out of the box? I'd like to see that. There's basically nothing you can't implement with Git, but for a setup this confused, you'll have to find somebody who knows their stuff and can be persuaded to do it on some terms. – jthill Nov 04 '20 at 22:07
  • @jthill I'd like to see it too!! That's why I'm asking! :) (I like "swamp" - a very apt name) – Luke Nov 04 '20 at 22:10
  • To get acquainted with the Git tools you'd need to implement this,see [here](https://stackoverflow.com/questions/23726408/how-to-track-revision-history-of-revision-history/23746356#23746356), that shows some slicey-dicey-merge-em-nicey on related histories, but you'd have to play some pretty scary games with `.git/info/exclude`s or ... actually, no, here's where you look: treat *all* of the histories as submodules and your build environment as a makefile target you construct from something Git can already handle easily. – jthill Nov 04 '20 at 22:16
  • @jthill ok thanks! Really appreciate the suggestion - I'll look into this!! – Luke Nov 04 '20 at 22:32

0 Answers0