On Mon, Jul 13, 2020 at 01:04:54PM -0700, Junio C Hamano wrote: > Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> 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