Re: [PATCH 2/2] send-email: don't needlessly abs_path() the core.hooksPath

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, May 25 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.