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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey

On Tue, 25 May 2021 at 03:03, Junio C Hamano <gitster@xxxxxxxxx> 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?

I don't think I have a good reason why abs_path() was used, most
likely it was copied from some other snippet and kept for uniformity.

>
> 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?

Previously this functionality was entirely not working, so I don't
think we'll have any regressions. With that being said I'm unable to
test that it works well on windows.

As far as what the expected norms for paths are within git, I really
don't have any answers.

>
> Puzzled.
>




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux