3

I need to automate the following step:

git clone A && cd A && (git clone B; git clone C)

I cannot use submodules. I cannot use a git wrapper (already existent or by writing some function in my *$shell_rc).

H. Pauwelyn
  • 13,575
  • 26
  • 81
  • 144
Andrea Scarpino
  • 791
  • 6
  • 13

3 Answers3

2

You can use an alias

alias gitclones='git clone A && cd A && (git clone B; git clone C)'

Or you can define a custom wrapper (not git itself but a bash script in the user's path)

But the git way would be to use submodules, in which case a simple git clone --recursive --remote would be enough.
You can make a submodule to follow a branch like master.
See "Git submodules: Specify a branch/tag"

Note that repo B and C will be consider as nested repo, only their gitlink will be recorded in A.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @ilpianista git aliases are not shell configurations, they're stored in `~/.gitconfig` – Яois Dec 21 '15 at 09:08
  • 1
    @ilpianista I have edited my answer: you can make a submodule follow a branch – VonC Dec 21 '15 at 09:08
  • @KeillЯandor true, but I cannot touch .gitconfig neither. The user that fetches the code doesn't have to know that project A needs B and C. – Andrea Scarpino Dec 21 '15 at 09:09
  • @VonC didn't know that! I'm reading http://stackoverflow.com/questions/9189575/git-submodule-tracking-latest/9189815#9189815 right now – Andrea Scarpino Dec 21 '15 at 09:10
  • @VonC the problem with submodules is that gitlink. project A always should point to latest master of B and C. – Andrea Scarpino Dec 21 '15 at 09:22
  • @ilpianista it will: a `git submodule update --remote` will take care of that in order to update those submodules to the latest of master. – VonC Dec 21 '15 at 09:24
  • @VonC in a perfect world your anwser would be the correct approach, but I've to deal with some people and then I'll use a post-checkout hook. Thank you anyway! – Andrea Scarpino Dec 21 '15 at 10:20
  • @ilpianista the post checkout hook can do the `submodule update --remote` I mentioned. I maintain submodules are the right tool for the job. – VonC Dec 21 '15 at 10:22
  • The problem I see is that project A has to be updated to point to latest commit everytime you commit on projects B and C. – Andrea Scarpino Dec 21 '15 at 10:45
  • @ilpianista that is not a problem: that is a feature in order to memorize which version of B and C were working with project A: that is the *all* point behind submodule. Otherwise, you have no idea how to reproduce a stable state of your project. – VonC Dec 21 '15 at 11:17
  • @VonC you can reproduce it by looking at jenkins builds. I know it s*cks. – Andrea Scarpino Dec 21 '15 at 14:36
  • @ilpianista sure: your first build step in your Jenkins job would be a `git submodule update --remote`, which would synchronize each submodule to their respective upstream master latest commit. – VonC Dec 21 '15 at 14:38
2

I would simply add a script addExternals to the top-dir of the repo, and mention it in the README. You might consider adding a call of it to the build system, but I think it's best if you leave the control of the subrepositories to the user.

The reason why I believe that this is the best approach: You cannot influence your users before they have cloned the repository, and they need to be aware of the fact that you are relying on subrepositories which are not modules. If you just invoke some magic to get the subrepositories into place, your users will trip over it later when one of the subrepositories needs to be updated to make the main repo compile again.

cmaster - reinstate monica
  • 38,891
  • 9
  • 62
  • 106
  • "If you just invoke some magic to get the subrepositories into place, your users will trip over it later when one of the subrepositories needs to be updated to make the main repo compile again." - so true! – Andrea Scarpino Dec 21 '15 at 10:24
  • @ilpianista While I agree with exposing subrepositories to the users, having a script to be manually called sounds like reinventing the submodules wheel. Why exactly you cannot use submodules? – Antonio Pérez Dec 21 '15 at 11:25
  • @AntonioPérez the problem with them is that you manually have to update project A to point to the latest commit of B and C everytime you commit on them. I like submodules, but my boss doesn't like this behavior I just described. – Andrea Scarpino Dec 21 '15 at 14:38
  • But you would have to explicitly call the `addExternals` script anyway when you commit on B or C in order to update A. So I don't see any benefit, and I see the disadvantage of maintaining the script yourself. – Antonio Pérez Dec 21 '15 at 14:50
1

You could use a post-checkout hook. Thus, you could have your repositories B and C getting updated if user switches branches/refs in A.

Antonio Pérez
  • 6,702
  • 4
  • 36
  • 61
  • Can I ship an hook with a repo? Or it has to be downloaded first? – Andrea Scarpino Dec 21 '15 at 10:10
  • No, it would require each clone to have the hooks manually initialized (you may have a script to provide a single-step initialization). See http://stackoverflow.com/q/427207/198011 – Antonio Pérez Dec 21 '15 at 10:13
  • Then basically this is the same of shipping a script with project A and tell people to run that script to fetch subprojects. – Andrea Scarpino Dec 21 '15 at 10:15
  • Well, they will need to run that script only once, then the hook would take care of keeping B & C updated if it is required. If B & C are not expected to change across branches, the hook is probably not a good solution to your needs. – Antonio Pérez Dec 21 '15 at 10:18
  • You are correct when you say that branches/refs could change, so yes the hook is a better approach. – Andrea Scarpino Dec 21 '15 at 10:19