#342 adds submodule update, but there is some hard-coded info about the submodules in the project files that isn't updated yet. (Commit hash, commit depth/count.)
|
<GitCommitCount>6908</GitCommitCount> |
|
<GitCommitHash>38031f6e5c3e21fa39d82aca300f5ed769be10a0</GitCommitHash> |
|
<LatestCommit>36f70fa4be4bd37d4d76d06dd2cc433ff46351bd</LatestCommit> |
This tracks auto-updating that metadata when the submodule is updated.
A few obstacles:
- GitHub doesn't seem to have an API for commit depth of a commit. The only API solutions I could find online are traversing the entire list of commits (using a large chunk of the account's rate limit) and counting pages (which assumes that the number of commits each page has is constant). What I have in mind is pointing the updater to the submodule, then it can
git fetch ... and use Git commands to get the depth.
- There doesn't seem to be a standard name for the commit hash and depth variables yet. I think standardization is the way to go to keep the updater config (source-build's
dependencies.props/targets) straightforward.
#342 adds submodule update, but there is some hard-coded info about the submodules in the project files that isn't updated yet. (Commit hash, commit depth/count.)
source-build/repos/cli.proj
Lines 10 to 11 in e2ecb4c
source-build/repos/coreclr.proj
Line 11 in e2ecb4c
This tracks auto-updating that metadata when the submodule is updated.
A few obstacles:
git fetch ...and use Git commands to get the depth.dependencies.props/targets) straightforward.