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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 25, 2021, 12:09 UTC
Message-ID: <87v977m2q6.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq35ubgwpy.fsf@gitster.g>

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

Show 15 quoted lines

> Æ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.