Have Dependabot offer submodule updates by EliahKagan · Pull Request #1702 · gitpython-developers/GitPython (original) (raw)

This extends the current Dependabot configuration so that, in addition to offering updates for GitHub Actions, it also offers them for git submodules (for the gitdb direct submodule).

This is to make updating the gitdb submodule more convenient, as well as making the its intended status relative to the head of gitdb clearer:

• PRs are set to be created monthly, or less often if the head of the gitdb repository has not advanced.
• They can also be triggered manually, so having them set monthly should never hold anything back.
• This proposal is not based on the idea that GitPython should always be kept up to date with gitdb. Dependabot PRs can be closed, and this signifies both to Dependabot and to humans that the specific update the Depedabot PR was for is not wanted at this time.

It is really that expressiveness that I regard to be the major benefit here: people can always check to see whether GitPython's submodule being behind the gitdb remote repository is intentional.

However, automatically creating PRs when situations like the one described in #1659 (comment) happen is also a benefit, and that is what gave me the idea to propose this. (For that in particular, I suggest updating the submodule separately from, and prior to, making new releases of either package or synchronizing dependency versions, to facilitate testing of the change, since the automated tests currently use the submodule version. If this PR is merged, then the resulting Dependabot PR for the update can also be merged.)

(There is a further benefits of using Dependabot for this: the Dependabot commands. Rebasing onto main can be done with @dependabot rebase, and merging after waiting for all CI checks pass can be done with @dependabot merge or, if no separate merge commit is desired, @dependabot squash and merge.)

Please note that my intention is not to prolong the GitPython repository's nontrivial use of submodules any longer than it would have been. I believe this change would not entrench that, because it is easy to revert or otherwise undo when no longer needed.

Although the actual gitdb submodule is located in git/ext/gitdb, I think specifying "/" as the directory in dependabot.yml is correct, because except where otherwise documented, Dependabot treats directory as the location of manifest files, which I believe it considers .gitmodules to be, for submodules, rather than the submodule itself.