Including 3rd Party Repository in my own Repo

Closed. This question needs to be more focused. It is not currently accepting answers.


Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed yesterday.

Improve this question

I’ve just got a git repository set up on gitlab for a project. The project I’m working on uses FreeRTOS.

I would like a way to have my online repo have a link to the FreeRTOS repo that will clone when the repo is cloned but doesn’t commit the FreeRTOS code to my repo.

It needs to link to a specific FreeRTOS commit but, if possible, I’d like to be able to choose to update that commit version if I want.

Currently I have the 11.2.0 FreeRTOS tag for my project and every clone of my repo should contain that code. If/when 11.3.0 comes out I want to be able to update by local repo, see if 11.3.0 works OK on my project and, if it does, update that link so that other clones of it use it as well. If, for some reason, 11.3.0 gives problems I want clones to get 11.2.0.

I’ve tried “git submodule” but that gave me no end of problems. Maybe I just did it incorrectly but I’ve read that it is a bit of a nightmare.

Currently using TortoiseGit as a GUI Client but if there’s something better or I need to use the Command Line to get this all set up, then there’s no problem with that.

I’m a technical person but I’ve never used Git “in anger”. Just basic operations and that was a few years ago now.

What You Want:

  • Link your GitLab project to a specific version of FreeRTOS.
  • Do not commit FreeRTOS code into your own repo.
  • When cloning your repo, FreeRTOS code should also be cloned.
  • You want the ability to easily update the version later if needed.

The Best Solution: Use a Git Submodule — but use it correctly

Despite the issues you had, submodules are exactly for this. You probably ran into trouble because submodules have quirks, but they do solve your problem cleanly if set up right.


How to Set It Up (Step-by-Step):

1. Add FreeRTOS as a submodule:

git submodule add -b master https://github.com/FreeRTOS/FreeRTOS-Kernel.git freertos
cd freertos
git checkout <commit-hash-or-tag>  # e.g., git checkout V11.2.0
cd ..
git add freertos
git commit -m "Added FreeRTOS 11.2.0 as submodule"

Replace <commit-hash-or-tag> with the specific version you want, like V11.2.0.


2. Clone the project with submodules (what others should do):

git clone --recurse-submodules <your-repo-url>

Or if already cloned:

git submodule update --init --recursive

3. To upgrade FreeRTOS later (e.g., to 11.3.0):

cd freertos
git fetch
git checkout V11.3.0
cd ..
git add freertos
git commit -m "Update FreeRTOS to 11.3.0"

Why Submodules Work for You:

  • Tracks specific commit
  • Not stored in your repo
  • Users get the exact version you set
  • You control updates

Tools:

  • TortoiseGit supports submodules but is clunky for them.
  • Use command line for submodule actions — it’s safer and more predictable.

Common Pitfalls (to avoid):

  • Not using --recurse-submodules on clone.
  • Not committing .gitmodules file.
  • Forgetting to git add after switching submodule commit.