8

This may be terrible, I am not sure.

Let us say we have a repo "product" with a working directory

/product
/product/command.script
/product/config/ (bare git repo)

And a repo "config" with a working directory

/config
/config/config.json

The command.script file has actions to interact with a bare repo. ex. Running command.script BRANCH1 would run the command

git show BRANCH1:config.json

Is there any way that the "/product/config/" folder can be a submodule of the "product" repo, such that when the "product" repo is cloned the "config" repo will also be cloned 

git clone --bare [config origin here] config

from its origin and when the "product" repo is fetched, the "/product/config" submodule can be fetched 

git fetch origin '*:*'

Or is this something that should be handled through hooks of some sort?

Tyler Clendenin
  • 1,459
  • 1
  • 12
  • 25
  • 1
    Allow bare submodules: I don't think so. – linquize Aug 28 '14 at 01:35
  • @linquize Why not? It will make a "full" repo backup a much simpler. At least the `--mirror` option is available only in a bare variant, so you have to clone twice: as a bare repository and as not bare. – Andry Jan 31 '23 at 00:05

1 Answers1

4

No: when the repo "product" is fetched, its index will include a gitlink (special entry recording the SHA1 of the submodule).

That entry can only be used in a non-bare repo, in order to be expended as a nested (submodule) repo.

That is why the git clone man page mentions:

--recursive
--recurse-submodules

After the clone is created, initialize all submodules within, using their default settings. This is equivalent to running git submodule update --init --recursive immediately after the clone is finished.
This option is ignored if the cloned repository does not have a worktree/checkout (i.e. if any of --no-checkout/-n, --bare, or --mirror is given)

That means it is best for the config repo to be cloned separately (even bare) at the right SHA1 (the one recorded by the gitlink in the first product repo), and for the git show BRANCH1:config.json to be executed in that other cloned repo (with git -C).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you, I did not know they added the -C switch either. That will be usefull. So hooks would not be a good way to go? – Tyler Clendenin Aug 28 '14 at 11:48
  • @TylerClendenin yes, a clone --bare allows for a repo to be push to (you can push to a bare repo). You can then add a post-receive hook to perform any process you want, as I explained yesterday in http://stackoverflow.com/a/25499592/6309. – VonC Aug 28 '14 at 11:52