0

The Problem

I have a git-repository "installer" and a git repository "library". I want a subfolder/tree of the library repo to be a permanently updated submodule in a subfolder of the installer.

Which should look like this: installer/installer-package/lib/stdlib where stdlib is in library/stdlib

My Question

Is that possible and if yes, how?

I have tried

...installer/installer-package/lib/ $ git submodule add -b main <url to stdlib>

Which put the root directory of the library-repo in lib

xtay2
  • 453
  • 3
  • 14
  • What does "permanently updated" mean? – torek May 27 '22 at 21:40
  • Every time that the library repository changes, these changes are automatically pushed to the installer remote too – xtay2 May 28 '22 at 11:58
  • Git only deals with commits, so to get this effect, you'll have to monitor which commit is "the library repository commit" (however you define *the* commit: remember that a repository is a continuously growing database of many commits, each of which is on some number of branches; perhaps you want a particular branch's tip commit hash ID here). Then if the library version changes, build a new installer and install it. But that's a recipe for disaster *unless* that's just your CI/CD test setup. – torek May 28 '22 at 14:10
  • @torek The installer should have access to the newest version of the main branch of the library. I can't really see how this is problematic. – xtay2 May 29 '22 at 20:31
  • So, what's your plan here? Will you poll the repository once per second to check for updates? If not, how often will you poll? Suppose someone pushes some update, only it *doesn't work*. The build breaks, or worse, the build goes fine but the software doesn't do what it's supposed to. Who notices, and when? That's what a CI/CD system is for: it gets notifications from the host system, so that it doesn't have to poll, and it runs tests, so that you don't *install* an obviously-broken build. Hence that's why it sounds like you're looking for a CI/CD system. – torek May 30 '22 at 00:16
  • Note that none of the above is a *Git* issue specifically. It's version-control agnostic. But that's the real problem to solve: how will you do your CI/CD. Once you know *that*, *then* you decide how to work around the fact that in Git a submodule is intended to be totally static. – torek May 30 '22 at 00:17
  • If there's a human in the loop, everything is a lot easier. Don't run `git submodule update` at all: run your build script, which updates each item separately (however you prefer to do that) and then builds. The fact that you've chosen submodules here becomes largely irrelevant, at least for this build-script that you write: it just runs `(cd path && git fetch && git merge)` or whatever for each path. – torek May 30 '22 at 00:20
  • I'll add here that I might have this entirely upside down, because I still don't have a clue why you want to "continuously update" some remote site. – torek May 30 '22 at 00:35
  • @torek My main problem is not the real-time update, but the subfolder-problem. I'm just very new to the concept of git submodules and thought, that there is maybe something that can be enabled to allways sort of "link" to the newest version of said subfolder. – xtay2 May 30 '22 at 09:37
  • There isn't: the point of a submodule is that someone over on host H controls, say, the foo library. You've made your program work with foo version 1.2, commit `a123456`. You know your program works with *that* version. You'd copy the entire library into your own repository, but you don't want to go that far: instead, you just want to say "my program works with commit `a123456` of foo" so that's what your submodule records. – torek May 30 '22 at 11:05
  • Later, when you're working on your project, you notice that foo version 2.0 is out. You test it out. It doesn't work; you stick with `a123456`. You notice v2.1 is out, you try that, it works and has something new that you want: you declare your program works with commit `b789abc` of the foo library. These "I declare my program works with version of " are precisely what submodules *are*. – torek May 30 '22 at 11:06
  • The `-b` option for `git submodule add` tells Git that when you, a human, run `git submodule update --remote`, that's what *branch name* your Git should look up in the submodule, for testing purposes. Your Git will `git checkout` that raw hash ID *in* the library submodule. You test it: if it works, you take it, if not, you don't take it. Nothing here is *automatic*. – torek May 30 '22 at 11:07
  • Note that the "I declare" hash IDs are *per commit in your superproject*. So checking out commit `feedcab` in your project, and running `git submodule update` in your (super)project, gets you the "right" submodule hash to go with `feedcab` in your (super)project, as recorded in the commit (ie in `feedcab`). It's only while developing and testing that you might check out some submodule commit that's *not* recorded in a superproject commit. – torek May 30 '22 at 11:09
  • @torek Okay, well. I can certainly write a scipts that updates everything when necessary. Further on, there wont be compatibility issues because the installer isn't dependent on the library, but packages it into the file. As I said: The main problem is that I don't know how to exclusivly import a subfolder of the library repo. Do you know how to do that? – xtay2 May 30 '22 at 13:38
  • Git is, alas, not very well equipped to do this. The `git subtree` code is meant for this sort of thing but it's kind of flaky and poorly supported in the Git releases. – torek May 31 '22 at 05:45

1 Answers1

0

I have now found out, that this problem is currently not supported by git.

There is also this duplicate which explores the question further.

xtay2
  • 453
  • 3
  • 14