On Sun, Jul 12, 2020 at 01:52:17PM -0700, Junio C Hamano wrote: > Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> 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
