On Tue, May 25 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> In c8243933c74 (git-send-email: Respect core.hooksPath setting, >> 2021-03-23) we started supporting core.hooksPath in "send-email". It's >> been reported that on Windows[1] doing this by calling abs_path() >> results in different canonicalizations of the absolute path. > > I see the author of that patch CC'ed; the change in question > explains why we switched from "the hooks directory immediately under > $repo->repo_path()" to "ask 'rev-parse --git-path hooks'", but it > does not say why we call abs_path() on the result. I guess that is > because $repo->repo_path() has always been a result of applying the > abs_path() function to something, so it was to safeguard the callers > that expect an absolute path coming back from hooks_path? > > And that makes this change dubious, especially as a band-aid for a > breakage immediately before the final release, doesn't it? Are we > convinced that the callers are OK with seeing sometimes relative > paths? Certainly the cases the tests J6t fixed are not negatively > affected, but is that sufficient? To what directory is the > configuration variable supposed to be relative to, and are we sure > that the user will always invoke "git send-email" from that > directory? The one caller is git-send-email.perl is fine with it, at least on *nix, this fix still needs testing on Windows. The repo_path() function was introduced in c8243933c74, so it's never been in a release, thus I think it's fine to alter its behavior. The code here doesn't need to concern itself with what needs to be relative to what, you run send-email in some working tree directory (or top-level), and depending on core.hooksPath we'll either return a relative path to the .git/hooks or an absolute one, the system() invocation will accept either.
