From: Junio C Hamano <gitster@pobox.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/5] fetch doc: update introductory part for clarity
Date: Fri, 30 May 2014 14:27:00 -0700 [thread overview]
Message-ID: <xmqq61kn7yaj.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5388D857.7010705@xiplink.com> (Marc Branchaud's message of "Fri, 30 May 2014 15:13:27 -0400")
Marc Branchaud <marcnarc@xiplink.com> writes:
> The docs say that all the fetched refs are written to FETCH_HEAD (perhaps a
> more accurate name would have been FETCH_HEADS?). If that's truly the case,
> it seems weird to use FETCH_HEAD in log and merge commands. (My FETCH_HEAD
> file currently has 1434 lines in it -- what does that mean, and what does it
> imply for those log and merge commands?)
The "fetch" that was run by "pull" would have arranged the single
remote ref that your "pull" merged to your then-current branch to
the very beginning of FETCH_HEAD, so "git log FETCH_HEAD" would show
the line of development from that ref, and "git merge FETCH_HEAD"
would also merge what your "pull" would have merged.
> Perhaps FETCH_HEAD shouldn't be mentioned at all in the introductory part of
> fetch's man page.
A possible downside is that unreasonable people can use the lack
of mention of FETCH_HEAD as an excuse to start making noises about
removing the feature.
Also, a natural way to peek into somebody else's history without
making a permanent damage to your own repository, is:
$ git fetch $repository_of_marc master && git log FETCH_HEAD
As such a one-shot fetch from a random place does not use (and does
not want to use) any remote-tracking branch, knowing that FETCH_HEAD
is available for such a purpose would help people who want to script
such a thing.
next prev parent reply other threads:[~2014-05-30 21:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-29 22:42 [PATCH 0/5] Documentation updates for 'git fetch' Junio C Hamano
2014-05-29 22:42 ` [PATCH 1/5] fetch doc: update introductory part for clarity Junio C Hamano
2014-05-30 14:35 ` Marc Branchaud
2014-05-30 17:52 ` Junio C Hamano
2014-05-30 19:13 ` Marc Branchaud
2014-05-30 21:27 ` Junio C Hamano [this message]
2014-06-02 15:21 ` [PATCH] fetch doc: Move FETCH_HEAD material, and add an example Marc Branchaud
2014-06-02 18:24 ` Junio C Hamano
2014-05-29 22:42 ` [PATCH 2/5] fetch doc: update note on '+' in front of the refspec Junio C Hamano
2014-05-30 14:35 ` Marc Branchaud
2014-05-30 17:54 ` Junio C Hamano
2014-06-02 15:37 ` Marc Branchaud
2014-05-29 22:42 ` [PATCH 3/5] fetch doc: remove notes on outdated "mixed layout" Junio C Hamano
2014-05-29 22:42 ` [PATCH 4/5] fetch doc: on pulling multiple refspecs Junio C Hamano
2014-05-29 22:42 ` [PATCH 5/5] fetch doc: update refspec format description Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq61kn7yaj.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=marcnarc@xiplink.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.