Re: FETCH_HEAD files and mirrored repos

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jul 12, 2020, 21:54 UTC
Message-ID: <20200712215433.cfjyqzaepsuktny2@chatter.i7.local>
In-Reply-To: <xmqqr1tgpibi.fsf@gitster.c.googlers.com>

On Sun, Jul 12, 2020 at 01:52:17PM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
> 
> > I also discovered that symlinking FETCH_HEAD to /dev/null works as well 
> > and thus saves a few IO cycles.
> 
> We could teach "git fetch" a new "--write-fetch-head" option and
> teach "git pull" to pass it when calling "git fetch".  It is very
> plausible that some folks rely on "git fetch" to leave FETCH_HEAD
> without being told, so the option must default to on for a few
> development cycles before we flip the default to off, and for those
> who want to live in the future a bit earlier, we can also introduce
> fetch.writeFetchHEAD configuration variable that determines what
> happens when "git fetch" is run without "--write-fetch-head" option
> on the command line.  That way, you could drop 
> 
> 	[fetch]
> 		writeFetchHEAD = 0
> 
> in say /etc/gitconfig or in ~/.gitconfig of the user that runs the
> mirroring automation.

Yeah, that would be great for me. We can simply leave it on by default to preserve existing behaviour and just provide a way to disable writing it for those in fairly unique situations where that matters (like mine). One downside of symlinking it to /dev/null is that it creates a potential pitfall for software that expects FETCH_HEAD to always be a regular file and can behave unpredictably when it finds anything else there.

Thanks, -K