Adds a field to individual sources that allows overriding the --recurse flag

[paulhovey]

When doing gitman update, there's an option for --recurse (which, this could probably be documented better, as it's only mentioned directly in the API page: https://gitman.readthedocs.io/en/latest/interfaces/api/ )

Sometimes I have multiple repositories but only want to recursively update some of them, and this is the functionality in this PR. There's a new flag in gitman.yml repositories that will override the --recurse flag if it is present, and default back to that flag if not present. That means existing functionality is unchanged, but users can choose to either recurse into directories of their choosing, or recurse into all except directories of their choosing.

[jacebrowning]

I'm not sure what --recurse flag you are referring to.

The --all flag in gitman update means to also pull in the latest versions of their dependencies rather than just checking out the last pinned version.

Does --depth perhaps fulfill your need?

[paulhovey]

No, depth is just the level of the git repository to be cloned (full history or just surface-level history), and what I'm trying to do is prevent gitman from going into every nested repository and reading the gitman.yml. I'm pretty sure (and you can correct me if I'm wrong about this) is that for every repository in the root gitman.yml the initial clone happens, and then gitman goes into the repository and checks for a nested gitman.yml and then clones those repositories as well, continuing on until there are no more gitman files and repositories to clone. I want that behavior for some repositories, but not all of them, and right now I think it's an all-or-nothing approach to this. Is that correct and reasonable?

[jacebrowning]

Yes, your understanding is correct. Can you expand on why you want this capability? I believe most or all package managers install the dependencies of their dependencies. To opt out of that could leave the setup in an incomplete, broken state.

[paulhovey]

That's a fair question, and why I'd want to leave the default how it is but allow the configuration to disable on a by-repo basis. Basically if I have a repo of config files, I want to pull that down into a project, but that config file repo also has a dependency on the same repo as the originating project, so it's a double-dependency. So something like:

my-project/
├── libs/
│   └── core/                        # repo-core  (runtime logic)
│       └── .git/
├── config/
│   └── shared-config/               # repo-config (all repos depend on this)
│       ├── .git/
│       ├── settings.yaml
│       └── env/
├── apps/
│   ├── service-a/                   # repo-A
│   │   ├── .git/
│   │   └── (depends on: ../libs/core · ../config/shared-config)
│   └── service-b/                   # repo-B
│       ├── .git/
│       └── (depends on: ../libs/core · ../config/shared-config)
├── package.json
└── README.md

In that example, for my project I may not want service A and B to be redundant if I'm working in a global folder that has all my services with a shared core and config, or I could have a separate repository for service A and service B where I do want them to clone the configs for separate deployments.

You might say "well this is dumb and poorly architected" and you'd be correct, but sometimes you inherit a building you didn't design 🙂

As I said, I don't want the default behavior to change, but just to allow flexibility when needed for rare cases. If you disagree that's understandable too.

[jacebrowning]

Thanks for the explanation! I will think about it some more but this does feel like a niche use case to me.

I would probably manage that situation using the groups feature and call gitman install twice with --depth=0 when installing the services containing the shared dependencies.

[paulhovey]

Oh very interesting with the groups comment, I had missed that as a possibility! I'll explore that some too, thanks for the tip 🙂