Re: Git 2.18: RUNTIME_PREFIX... is it working?

From: Jeff King <peff@peff.net>
Date: Jul 10, 2018, 02:21 UTC
Message-ID: <20180710022141.GC10248@sigill.intra.peff.net>
In-Reply-To: <nycvar.QRO.7.76.6.1807092225120.75@tvgsbejvaqbjf.bet>

On Mon, Jul 09, 2018 at 10:26:54PM +0200, Johannes Schindelin wrote:

Show 16 quoted lines

> > Would it be reasonable to make RUNTIME_PREFIX the default on systems
> > where we _do_ have that support? AFAIK there is no downside to having it
> > enabled (minus a few syscalls to find the prefix, I suppose, but I
> > assume that's negligible).
> > 
> > I.e., a patch to config.mak.uname (and possibly better support for
> > _disabling_ it, though I think "make RUNTIME_PREFIX=" would probably
> > work).
> 
> The obvious downside is that we would be a lot more likely to break one
> side of the equation. At least right now, we have Git for Windows being a
> prime user of RUNTIME_PREFIX (so breakages should be caught relatively
> quickly), and macOS/Linux *not* being users of that feature (so breakages
> in the non-RUNTIME_PREFIX code paths should be caught even quicker). By
> turning on RUNTIME_PREFIX for the major platforms, the fringe platforms
> are even further out on their own.

That's true. On the other hand, we have a zillion compat features for fringe platforms already, so there already is an expectation that people on those platforms would need to occasionally report and fix system-specific bugs. Perhaps thinking of it not as an feature to opt into, but rather as a compat for "your system has not caught up to the modern world by implementing RUNTIME_PREFIX" would encourage people on those platforms to implement the necessary scaffolding.

I also have a gut feeling that it is much easier for static-path devs to break RUNTIME_PREFIX folks, rather than the other way around, simply because RUNTIME_PREFIX has a lot more moving parts. But I admit that's just a feeling.

-Peff