Daniel B.

I'm not sure if understand the question. Basically my idea is in addition to the recursive resolution stretegies where each repository stores it dependencies in a subdirectory similar to submodules...

Correct, that's the idea... This resolution strategy is similar to the dependency management of bower or the Perforce import Streams functionality. I have worked in large projects with dozens of...

In my experience this resolution strategy is much more helpful in large projects with many dependencies and a more complex dependency graph. There are also situations where it is quite...

After some prototyping, I think the best way to implement this feature is not introduce a seperate command option `--flat` and instead extend the configuration file to specify the flat...

The simplification could be done in scope of #170

I see some overlap to #128

We have a similar requirement solved by using seperate branches in the top level repository (like dev and prod) to maintain seperate gitman configs because of our many repositories and...

Maybe this helps, I have tried to illustrate it with an abstract example. The product repository here is `product_xy` which contains the global product related gitman.yml besides some other stuff....

> But when fx tf-network contains modules, these can also vary depending on the environment. According to my described approach, there is no nested gitman.yml and then I would arrange...

The basic use case is that I have a gitman.yml with a bunch of source dependencies. A couple of them can be logicaly grouped and this group information (why this...