Re: [PATCH v7 2/6] fsmonitor: relocate socket file if .git directory is remote

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

 





On 9/19/22 7:51 PM, Eric DeCosta wrote:


-----Original Message-----
From: Junio C Hamano <gitster@xxxxxxxxx>
Sent: Monday, September 19, 2022 1:49 PM
To: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx>
Cc: Eric DeCosta via GitGitGadget <gitgitgadget@xxxxxxxxx>;
git@xxxxxxxxxxxxxxx; Eric Sunshine <sunshine@xxxxxxxxxxxxxx>; Torsten
Bögershausen <tboegi@xxxxxx>; Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx>; Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx>;
Johannes Schindelin <Johannes.Schindelin@xxxxxx>; Eric DeCosta
<edecosta@xxxxxxxxxxxxx>
Subject: Re: [PATCH v7 2/6] fsmonitor: relocate socket file if .git directory is
remote

Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes:

Aren't we in the middle of a transition from always using the global
"the_repository" to a passed "r" variable?
We're getting closer to being able to hide the the global symbol, but
we're not there yet, right?

We may still have code that works ONLY on the_repository, but letting a
function take "r" and lettin it ignore is worse than leaving it explicitly limited
to the_repository only, no?

I'm thinking that at as long as the global exists, we are not safe to
have multiple "struct repository" instances, right?

By itself, Not at all.  It is the code like I am criticizing that makes it unsafe.

I do not mind adding

	if (!r)
		BUG(...);

at the place you have the "sweep it under the rug" band-aid, though.

Appreciate all the insights and comments. Where are we landing with this? Very close to the finish line and I'd like to be able to push these changes over that line.

-Eric


I'm OK doing it either way.  Junio seems to prefer the BUG() version,
so let's go with that.  That lets us make progress on getting rid of
direct references to "the_repository".

Jeff



[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