Re: FETCH_HEAD files and mirrored repos

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

 



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



[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