Re: FETCH_HEAD files and mirrored repos
- From
Jeff King <peff@peff.net>
- Date
- Jul 13, 2020, 20:22 UTC
- Message-ID
- <20200713202211.GA2355588@coredump.intra.peff.net>
- In-Reply-To
- <xmqqtuybmba1.fsf@gitster.c.googlers.com>
On Mon, Jul 13, 2020 at 01:04:54PM -0700, Junio C Hamano wrote:
Show 15 quoted lines
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes: > > > Does it make sense to add logic for whether this is done in a bare repo? > > I can't imagine common cases where a FETCH_HEAD would be useful outside > > of a checkout where a merge is likely to happen. > > It is entirely valid to respond to a one-shot "My work is published > there; could you see if I am doing anything obviously wrong?" with > > git fetch git://k.org/somebody/linux.git check-me-please > git log ..FETCH_HEAD > git diff ...FETCH_HEAD > > i.e. without touching any of our refs, and possibly in a bare > repository, no?
I occasionally use FETCH_HEAD for such things. If we were to stop writing it automatically, I think the key thing to notice is whether the result was actually stored anywhere else. Or more accurately, whether the user asked for any refspecs on the command line (since we'd still update tracking refs in some cases).
If I do:
git fetch
or:
git fetch origin refs/heads/foo:refs/heads/foo
then I probably don't care about FETCH_HEAD. But if I do:
git fetch origin refs/heads/foo
then I'm probably interested in picking the result out of FETCH_HEAD.
-Peff