Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cope with safe.bare repository=explicit #116

Closed

Conversation

dscho
Copy link
Contributor

@dscho dscho commented Dec 12, 2023

Since Git v2.38.0, safe.bareRepository is a thing. When a user configures this with the value explicit, Git invocations will fail on bare repositories unless GIT_DIR is set (either explicitly or via --git-dir).

The tests of git sizer will currently fail in such a scenario because they invoke Git inside bare repositories without setting GIT_DIR.

A more subtle issue arises when calling git sizer in a non-bare repository while safe.bareRepository=explicit is in effect: The call to git rev-parse --git-path shallow is not performed in the worktree but in the Git directory. For reasons, Git treats that situation identically to being called in a bare repository, and refuses to perform the operation.

Let's fix both of these issues so that the tests pass and so that git sizer works as expected in user setups that have safe.bareRepository set to explicit.

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.

Let's just override whatever value the system or user-wide Git config
has for that config setting, to ensure that the tests can pass.

Signed-off-by: Johannes Schindelin <[email protected]>
When a user has configured `safe.bareRepository=explicit` in their
user-wide Git config, any Git call will fail when the current directory
points inside a Git directory unless `GIT_DIR` is set (either explicitly
or via `--git-dir`). This extends to the Git directories of non-bare
repositories, too, because Git does not really have any way to discern
between them and bare repositories.

Therefore, we need to make sure that that `GIT_DIR` is set when calling
Git from inside a Git directory.

Happily, there is only one Git invocation that needs to be fixed.

Signed-off-by: Johannes Schindelin <[email protected]>
@dscho dscho requested a review from a team as a code owner December 12, 2023 20:29
@dscho dscho requested a review from mhagger December 13, 2023 10:13
Copy link
Member

@mhagger mhagger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I understand correctly that the first git invocation in NewRepository, i.e.

git -C $path rev-parse --git-dir

would still be expected to fail if

  1. the user has safe.bareRepository=explicit set,
  2. path is within a bare repository, and
  3. the user hasn't set GIT_PATH before running git-sizer

? If so, I think that correctly reflects what the user would expect given that they made that config setting.

In other words, the change only has an effect when that first command would succeed but the second command would have previously failed, namely when

  1. the user has safe.bareRepository=explicit set,
  2. path is within a non-bare repository, and
  3. the user hasn't set GIT_PATH before running git-sizer

, and that's specifically because git rev-parse --git-path shallow is treated differently than typical git commands.

If that's all correct, then the change seems good to me aside from the problem that I pointed out in a line comment, which I think needs to be addressed.

@@ -64,8 +64,7 @@ func NewRepository(path string) (*Repository, error) {
gitDir := smartJoin(path, string(bytes.TrimSpace(out)))

//nolint:gosec // `gitBin` is chosen carefully.
cmd = exec.Command(gitBin, "rev-parse", "--git-path", "shallow")
cmd.Dir = gitDir
cmd = exec.Command(gitBin, "--git-dir", gitDir, "rev-parse", "--git-path", "shallow")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this change, it is no longer correct to call shallow := smartJoin(...) below, because git rev-parse --git-path is documented to return the path to the file relative to the current directory. Therefore, I think that the line below should be changed to shallow := string(bytes.TrimSpace(out)).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. But since you offer a much improved solution with #117 that basically supersedes this here PR, I will simply close this PR instead ;-)

@mhagger
Copy link
Member

mhagger commented Dec 13, 2023

When reviewing this PR I found a bunch of things about repository initialization that were gratuitously confusing. What would you think of #117, which does some cleanup and then fixes this issue, instead?

@dscho
Copy link
Contributor Author

dscho commented Dec 13, 2023

Do I understand correctly that the first git invocation in NewRepository, i.e.

git -C $path rev-parse --git-dir

would still be expected to fail if

1. the user has `safe.bareRepository=explicit` set,

2. `path` is within a **bare** repository, and

3. the user hasn't set `GIT_PATH` before running `git-sizer`

? If so, I think that correctly reflects what the user would expect given that they made that config setting.

This matches my understanding.

@dscho dscho closed this Dec 13, 2023
@dscho dscho deleted the cope-with-safe.bareRepository=explicit branch December 13, 2023 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants