Have Dependabot offer submodule updates

[EliahKagan]

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.

[Byron]

That's a great catch! I forgot that CI here was testing with an older version of gitdb, and dependabot with this configuration should help discover when these go out of sync.

I also update gitdb by hand now, for good measure, which might have been a mistake as dependabot probably won't trigger now. (let me undo it - done).

directory probably even defaults to 'root' as this is the default location, but if it doesn't work we can always fix it. Let's try :).

[EliahKagan]

The status should be shown in the Dependabot tab of the Dependency Graph page.

(I can't access that, but I believe it is the correct URL.)

[Byron]

Oh, right, I wasn't aware!

Indeed it's already active, maybe it will produce a PR soon.

[EliahKagan]

Nice! :)

I considered also opening a PR like this in the gitdb repository so that its smmap submodule would be updated automatically. That is updated less often, though, and I'm not sure it would really be worthwhile to do that. If you think it is, I'll open such a PR as well.

Edit: I see that Dependabot has successfully created a PR, #1704. (If you comment with @dependabot merge, or @dependabot squash and merge, it will wait until CI passes and, only if it passes, then merge the PR automatically. You need not do this, of course.)

[Byron]

While these repos exist, it's probably worth it (even though smmap truly changes rarely.). Thanks for your tremendous help.

[EliahKagan]

I will do so shortly. Given this, I suggest not yet merging the existing Dependabot PR here (via commands or otherwise). May as well wait for the submodule update from the gitdb PR being merged there. No need to do anything at all on #1704 actually; when Dependabot opens a new one for that same dependency, it will automatically close #1704, though you may need to trigger Dependabot manually to do another scan to see it.

[EliahKagan]

I've proposed the analogous change to gitdb (for updating the smmap submodule) in gitpython-developers/gitdb#99.

[Byron]

It looks like it doesn't automatically trigger now, probably due to the weekly cadence. I guess it's fair to merge the one open PR now and wait for the next one (as also I can't trigger a scan by hand).

[EliahKagan]

I think it's worth looking into why you can't manually trigger it, before merging #1704.

[Byron]

Sorry, that was too late. It's fine to me as well - maybe I was just overlooking something - turns out I was not seeing the button that at least now is there. Now it's scanning.

[EliahKagan]

It's allowing you to manually trigger the scan now?

[EliahKagan]

Oh, I see. When you said it was too late, you meant you had already merged the first one. I think that's no problem at all, though.

[EliahKagan]

probably due to the weekly cadence

The cadence for action updates is set to weekly, but I actually set the cadence for submodule updates to monthly, both here and in gitdb. Would you prefer it be weekly?

If so, I could open new PRs for that. Editing dependabot.yml always triggers new scans, so if you prefer weekly cadence but don't want more scans right now, I could wait until next time I'm already proposing some other change to gitdb to do that in both repositories. (I have no other specific change in mind currently but I'm fairly sure I'll end up opening another PR there at some point.)

[Byron]

Yes, please feel free to change the cadence next time you get to it 🙏 - a PR specifically for that right now isn't necessary though.

[EliahKagan]

I've opened #1721 and gitdb#104 to change the cadence of Dependabot submodule updates from monthly to weekly, in this and the gitdb repository, respectively. With recent and proposed changes to gitdb, this seemed like a reasonable time, but for maximum flexibility I've opened them as their own PRs instead of including them in other PRs.