I suspect that it may have to do with tracking the different versions of the same file in git. If you want to be able to look up the history of a file, the easiest way is to keep the same filename all the time. Normally Git is able to detect when a file is renamed, based on contents, but in the case of RBFs, the content is so radically different between changes that when renaming and replacing in one operation, it considers them different unrelated files and is unable to trace the history to previous versions.
But it's still possible to do this with git. If you have, say, a file called jtoutrun_20230324.rbf and you want to update it to jtoutrun_20230331.rbf, you do this:
Replace jtoutrun_20230324.rbf with the new version, but WITHOUT changing the name. Keep the old name for now.
Do a commit with the replacement.
Use
git mv
to rename the file to the new name (in this example:git mv jtoutrun_20230324.rbf jtoutrun_20230331.rbf
).Do another commit with the rename.
That should allow you to track the history of jtoutrun_*.rbf. I'm not sure how well supported that will be in GitHub though, but in the command line you can do it with git log --follow <archive>
.