As of Git v2.38.0, there is an option to prevent Git from accessing bare
repositories unless asked for explicitly (via `--git-dir` or `GIT_DIR`):
`safe.bareRepository`.
The tests of `git sizer`, however, assume that Git will access a bare
repository when the current directory points inside that repository.
This only works if `safe.bareRepository` indicates that this is safe.
If that is not the case, i.e. if `safe.bareRepository` is set to
`explicit`, Git demands that the environment variable `GIT_DIR` is set
(either explicitly, or via `--git-dir`) when accessing bare
repositories.
So let's set `GIT_DIR` for the test cases that work on bare
repositories.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a method `Repository.GitPath(relPath)`, which invokes `git
rev-parse --git-path $relPath` to find the path to a file within the
Git repository.
In `NewRepository()`, instantiate the `Repository` object earlier so
that the new method can be used to find the path to `shallow`.
We needed a way to generate draft releases for git-sizer binaries.
This commit adds a new `.github/workflows/release.yml` github action
that will generate a draft release when a new tag version is pushed.
the action will be triggered After the tag is created and pushed using:
```
git tag -as v$VERSION
git push origin v$VERSION
```
Instead of only traversing objects starting at references, allow the
user to specify explicit Git objects via the command line. In that
case, the traversal includes objects reachable from those objects.
Some `git-config` options that we were using (`--default`,
`--type=bool`, and `--type=int`) were only added in git 2.18, released
2018-06-21. This means that some fairly recent platforms, like Ubuntu
18.04 "bionic", don't have those features in their default `git`.
Change `git.Repository` to invoke `git config` without using those
newer options.
In response to CVE-2022-39253, Git now considers the `file://` protocol
to be unsafe by default. The default value of the `protocol.file.allow`
config variable was changed to `user` [1], meaning that a file URL or a
local path is only trusted if it came directly from user input, and not
if it came through a command which executes a clone/fetch/push
internally.
The tests fall foul of this new requirement by attempting to run a
`git submodule add` with a local directory. Internally, this performs a
clone, which is no longer trusted because of the change described above.
This results in the command failing with a "transport 'file' not
allowed" message.
Since this is only the case for a single command, then fix the test by
setting `protocol.file.allow` to `always` when we run it.
[1] https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253