Question on workflow

[v-erena]

Trying to avoid to re-invent the wheel, I remembered this tool git-dependencies :)
I was trying out git submodules, which is not nice. git subtrees look better, but still seem quite complex. git subrepo, https://github.com/ingydotnet/git-subrepo, looks promising.
The major benefit of git-dependencies lies in the explicit, easy-to-maintain dependencies.yml.
But how is your workflow when working on code?

1. fresh clone of container project
2. installing git-dependencies (if not already done)

3. git dependencies init

4. work on container code: commit and push
5. work on dependency code: keep track of changes with git dependencies and then cd to the repo and do all git related stuff there.
   If I want to switch a branch of a dependency, I reconfigure that in yml.
   Do I understand that correctly?

[Nico Mandery]

Hi!

Your understanding is correct. The main idea of git-dependencies was to have a tool which allows to check out a driectory hierachy multiple repositories on a defined state with as little messing around with git as possible. One main feature during the creation of git-dependencies was to be able to reference a branch X of a dependency of the container project and simply build on the asumption that branch X will always have the matching code for the container project. This is quite helpful when you are in control of both projects - then there is not need anymore to track the exact referenced commit of the the dependency in the main repository, like a git submodule would require.

The drawback is of course that the developer has more responsibility to track & commit changes in the single repositories as each of those is a completely seperate repository itself. This gives more freedom for some projects by is certainly not optimal for every project.