Flat hierarchy resolution

[daniel-brosche]

i'm thinking about to implement a flat hierarchy resolution strategy like bower. I think it would be good extension to gitman as long it is configurable in the update or install method. What do you think?

[jacebrowning]

gitman list shows the full tree after installation. Do you have any thoughts on how this might be stored for later reinstall?

[daniel-brosche]

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 is to realize a flat resolution strategy where all dependencies are resolved in one folder. Recursive resolution of all dependencies but the storage in one folder, that's the idea. I have scenarios where this resolution strategy is quite benefitial. Of course resolution conflicts needs to be handled too and will happen more often instead of the recursive storage strategy. Does this answer your question?

[jacebrowning]

I think I understand. After running gitman install, instead of getting something like

.gitman.yml
vendor/
  dep_a/
    .gitman.yml
    vendor/
      dep_c
  dep_b/
    .gitman.yml
    vendor/
      dep_c

you would get something like:

.gitman.yml
vendor/
  dep_a/
  dep_b/
  dep_c/

where somehow you resolve dep_c to a single version. Does that sound right?

[daniel-brosche]

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 dependencies which are resolved in this way.
My idea is to switch the resolution strategy by a --flat argument which can be passed to the gitman update resp. gitman install operation.
Something like gitman install --flat.

[jacebrowning]

This feature sounds useful. It might even be worth having a flat: <bool> setting in the configuration file because you would want dependencies to be checked out the same on every machine.

[daniel-brosche]

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 harmful to import distinct dependency multiple times (dep_c v1.0 and dep_c v2.0). I would start to implement this feature soon because I need this feature for a complex embeeded system project.

[daniel-brosche]

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 dependency resolution.
Therefore I think, we could introduce a new string field resolve which is by default recursive and can be specified to flat. In the future we could add further strategies.

The following strategies are popped up in my mind:

• recursive: the default strategy
• flat: not recursive corresponds to --depth 1 (ignores nested gitman.yml files)
• flat-recursive: recursive in a flat hierarchy

Furthermore it would be helpful to define how conflicts should be handled.
As a first step I would throw an error if the same dependency has been resolved with different revisions.
Next, I see benefits to enforce the usage of a specified dependency revision which may be defined in the top level gitman.yml or to make dependency resolution interactive.

The locking of a flat hierarchy should work in the same way as defining all recursively resolved dependencies in the top level gitman.yml. Therefore it should list all resolved revisions in the sources_locked section (also from nested gitman.yml).