Resolve core.hooksPath relative to GIT_WORK_TREE #2571
Conversation
naseschwarz
force-pushed
the
issue-2281-fix
branch
3 times, most recently
from
22ad6a9 to
d66d148
Compare
git2-hooks/src/lib.rs
Outdated
| /// | ||
| /// # Panics | ||
| /// Panics if hook could not be created | ||
| pub fn create_hook_in_path(path: &Path, hook_script: &[u8]) { |
There was a problem hiding this comment.
If we just want this to be for testing, we might want to consider feature gating it so it does not become public api which would make it semver breaking to change
There was a problem hiding this comment.
I agree, git2_hooks::create_hook already has the same problem.
I've moved git2_hooks::create_hook_in_path into git2-testing. I've also moved git2_hooks::create_hook into a private mod and publish it via git2_hooks::test_utils::crate_hook only if the test-utils feature flag is set. (I can't move create_hook to git2-testing, as it has a dependency on "HookPaths".)
I'm open to as simpler and cleaner solution. Having this feature flag and the function in test_utils makes this a bit more explicit, but this is of course never tested or even built if all tests on this are run in this workspace with the flag enabled.
There was a problem hiding this comment.
If you want to deal with this discussion separately, I can easily move this into a separate PR by the way.
This is a function that's solely used in testing and has no dependencies into git2_hooks and panics on common errors. It's a much better fit for git2-testing.
git2_hooks::create_hook is a function used in tests, which panics on common errors. It can't really be moved into git2-testing, as it depends on git2_hooks::hookspath::HookPaths. In order to avoid accidental use, move the function into git2_hooks::test_utils[_priv] and only publish it as git2_hooks::test_utils if feature = "test-utils" is enabled.
git supports relative values in core.hooksPath. `man git-config`: > A relative path is taken as relative to the directory where the hooks are > run (see the "DESCRIPTION" section of githooks[5]). `man githooks`: > Before Git invokes a hook, it changes its working directory to either > $GIT_DIR in a bare repository or the root of the working tree in a > > non-bare repository. I.e. relative paths in core.hooksPath in non-bare repositories are always relative to GIT_WORK_TREE. There is a further exception; I believe this is not considered for path resolution: > An exception are hooks triggered during a push (pre-receive, update, > post-receive, post-update, push-to-checkout) which are always executed > in $GIT_DIR.
naseschwarz
force-pushed
the
issue-2281-fix
branch
from
d66d148 to
cda17c7
Compare
| @@ -18,7 +18,7 @@ dirs = "5.0" | |||
| easy-cast = "0.5" | |||
| fuzzy-matcher = "0.3" | |||
| git2 = "0.20" | |||
| git2-hooks = { path = "../git2-hooks", version = ">=0.4" } | |||
| git2-hooks = { path = "../git2-hooks", version = ">=0.4", features = ["test-utils"] } | |||
There was a problem hiding this comment.
wait this means we will always use its test-utils feature, not just for test-runs? is that intended?
There was a problem hiding this comment.
Yes. Do you prefer to set this feature flags only for tests?
We then have to always run tests with that feature flag and propagate it from the toplevel crate to git2-hooks. For gitui this is fine, as there's a request for running make check in the PR template. It may impede developers who just mechanically run cargo test --workspace, unless there is a way to enable a feature flags just for tests, which I don't believe there is.
I assumed enabling it for the workspace was okay, as your concern was semver breaking changes and dependencies are fixed within the gitui workspace. The way this is organized right now is not worse than before, at least, with semver concerns alleviated.
Thank you for looking at this.
There was a problem hiding this comment.
That being said, maybe we should just copy/paste the function to asyncgit for tests and not waste time on discussing or publishing a random feature flag that sounds fishy.
There was a problem hiding this comment.
yeah let’s do that 👍 simple and pragmatic
|
@Byron this might affect Gitbutler. Would love your pair of eyes |
git supports a relative path in core.hooksPath.
man git-config:man githooks:I.e. relative paths in core.hooksPath in non-bare repositories are always relative to GIT_WORK_TREE.
There is a further exception; I believe this is not considered for path resolution:
This Pull Request fixes/closes #2281.
It changes the following:
git2_hooks::create_hook_in_pathtogit2-testinggit2_hooks::create_hooktogit2_hooks::test_utils::create_hook, which is onlypubforfeature = "test-utils".I followed the checklist:
make checkwithout errors