As a workaround while https://github.com/orgs/community/discussions/191953 isn't implemented (that forum seems to be a black hole for feature requests and bug reports judging by the activity over the last few months).
We can use the Git Database API instead of the createCommitOnBranch mutation when commits contain unsupported content (or if explicitly requested):
- Large files.
- Symbolic links.
- Submodules.
- Executables.
- No parents (i.e., root commit of new branch).
I will probably still error for merge commits, since I can't think of a case where the user would actually want all the parents rewritten, and doing the necessary traversal to figure out where to start would add a lot of unnecessary complexity.
Since this endpoint doesn't create signed commits when using a personal access token, we need check if the created commit is signed (it's in the response) and error if it isn't.
The other downside of the REST API is the increased complexity and rate limit usage.
With this fallback, we will support everything git supports except for merge commits.
As a workaround while https://github.com/orgs/community/discussions/191953 isn't implemented (that forum seems to be a black hole for feature requests and bug reports judging by the activity over the last few months).
We can use the Git Database API instead of the
createCommitOnBranchmutation when commits contain unsupported content (or if explicitly requested):I will probably still error for merge commits, since I can't think of a case where the user would actually want all the parents rewritten, and doing the necessary traversal to figure out where to start would add a lot of unnecessary complexity.
Since this endpoint doesn't create signed commits when using a personal access token, we need check if the created commit is signed (it's in the response) and error if it isn't.
The other downside of the REST API is the increased complexity and rate limit usage.
With this fallback, we will support everything git supports except for merge commits.