git subtree not clear to me

[henrjk]

The git subtree commands at user-installation while nicely explained in a nutshell still look a bit complicated.

I was wondering what the implications would be as I stayed clear so far of git repo nesting. So this issue might be a knowledge gap on my end.

Questions I am wondering about:

• Does it make sense to fix ods-pipeline issues in our own repo meaning by changing and committing code below foo-cd/ods-pipeline? If so can these be contributed back if proven of general appeal?
• If I have custom images - not of general interest - for example for sidecars I assume it would be best to keep them separate for example in foo-cd/foo-pipeline/

While reading Mastering Git subtrees the author mentions git subrepo available at https://github.com/ingydotnet/git-subrepo#readme which at first glance looks potentially simpler.

There is also a google repo tool. Posting https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse.de/t/ suggests Google introduced the tool as an intermediate solution until git submodule would have advanced and the posting suggests that this time has come and that they would like to get rid of it.

Would it make sense to investigate our choice of consuming this repo via a git sub* method more?
What type of support is actually needed (beyond the documentation)?

Regarding the issues mentioned with submodules in https://github.com/opendevstack/ods-pipeline/blob/master/docs/adr/20210817-git-subtree-install.md:

• git submodule appears to support a path, which at first glance appears to eliminate the first problem mentioned.
• Can we elaborate on why users cannot customize tasks as they wish?

[michaelsauter]

Thanks for bringing this up! While ODS pipeline is currently using git subtree, that might not be the ideal or final solution. Happy to explore this.

Maybe some background helps here. I picked git subtree for three reasons:

1. I wanted to provide a way to describe the foo-cd namespace fully in a Git repository. For this, we need both the resources that are provided by the ods-pipeline repository on GitHub, and the project-specific values/secret files. Both git submodule and git subtree would work for this at first glance.
2. I wanted to allow that users can modify the resources provided by ods-pipeline. This is not possible with git submodule because you cannot modify content that is controlled by it. If one needs to change something related to the deployment resource of the webhook interceptor for example, that would not be possible to do with git submodule without leaving Git as the source of truth behind. Especially for regulated development it would be really nice if you could refer to your build environment simply by pointing to a Git SHA.
3. I just wanted to experiment with git subtree. I've always been intrigued by it but never had the use case for it, but now it seems to fit the bill :)

That aside, to your comments ...

While reading Mastering Git subtrees the author mentions git subrepo available at https://github.com/ingydotnet/git-subrepo#readme which at first glance looks potentially simpler.

I did not know of this before, however I would like to stay away from external dependencies as much as possible. The only downside I see with git subtree so far is that the UX is a bit clunky, but at least it is not something that one needs to do often and/or understand as a user.

Would it make sense to investigate our choice of consuming this repo via a git sub* method more?

When it comes to Git, I would like to stay with the options that are built-in. To my knowledge that is only git submodule and git subtree. git submodule has the drawback mentioned above so I think git subtree is the better choice for now. That said, maybe we should consider other ways to consume this repo. For example, we could also offer this as a Helm package that we simply consume via helm, instead of importing it via Git. This is something I'd like to explore more, but it would probably have the same limitations than git submodule. But it might be much easier to consume ...

Can we elaborate on why users cannot customize tasks as they wish?

I am not sure I understand this correctly. Do you refer to the cluster-wide ods-* tasks?