On Tue, May 25 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> 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. > > All of that are convincing, but I'd rather not risk it. I'll take > your 1/2 with J6t's fix, both of which are obvious and no brainer, > but I am willing to take this 2/2 as a post-release clean-up next > monght, though ;-) Fair enough. I get that we're in the rc phase, but FWIW I still disagree. I do think supporting whatever edge case we're exposing by round-tripping through abs_path() and its subtly different behavior is worse than a change to make us rely on the well-understood rev-parse behavior directly. Especially since the fix is to something that didn't work to begin with before the v2.32.0 release is out (core.hooksPath + send-email), but perhaps that's more of an argument for reverting the topic during RC + try to have it land in v2.33.0? And that + what seems to be the prevailing (IMO nonsensical) opinion on Git.pm's stability promise, meaning that once this new function is out in a release we'll be stuck supporting it makes me want to change this pre-release. But I'll leave it to you, if you are convinced and do want to take this 2/2 after all I'll submit another trivial patch on top to remove the new (then unused) repo_path function, which we expect to go away anyway.
