All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] docs: Explain the purpose of fetch's and pull's <refspec> parameter.
Date: Thu, 05 Jun 2014 15:12:15 -0700	[thread overview]
Message-ID: <xmqq61kfroow.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1401982803-22346-1-git-send-email-marcnarc@xiplink.com> (Marc Branchaud's message of "Thu, 5 Jun 2014 11:40:03 -0400")

Marc Branchaud <marcnarc@xiplink.com> writes:

> This patch applies atop your 8/9.  I feel strongly that some kind of
> reference should accompany this description, and your new CONFIGURED
> REMOTE-TRACKING BRANCHES section seems like a good one for the fetch
> variant, but since pull's variant doesn't have that section I just
> made it link to fetch's doc.
>
> (Also, I'm not sure if "CRTB" is a good link ID for your new section.)

Nobody looks at these ids, hopefully ;-)

> diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
> index 18cffc2..40304c6 100644
> --- a/Documentation/pull-fetch-param.txt
> +++ b/Documentation/pull-fetch-param.txt
> @@ -12,9 +12,20 @@ ifndef::git-pull[]
>  endif::git-pull[]
>  
>  <refspec>::
> -	The format of a <refspec> parameter is an optional plus
> -	`+`, followed by the source ref <src>, followed
> -	by a colon `:`, followed by the destination ref <dst>.
> +	Specifies which refs to fetch and which local refs to update.

That is an improvement.  We should first say what it is and what it
is for before saying how you spell it and the above change is
exactly that.

> +	<refspec> parameters are not normally specified on the command
> +	line, but instead are read from `remote.<repository>.fetch`

I however am not sure if this is an improvement, especially the
"normally" part.  Those who respond to a git-pull-request output
might be fewer than those who send pull requests, but that does not
mean they are abnormal.

	The command line often omit <refspec> parameters when
	fetching or pulling from a remote you regularly interact
	with, in which case `remote.<repository>.fetch` values are
	used instead.

would be OK, though.

Later today I'll push out the series on 'pu' after amending them
with your comments so far.  It would be nice if you can reroll this
on top of the updated one ("git log --oneline --first-parent
master..pu" and find jc/fetch-pull-refmap in there).

Thanks.

  reply	other threads:[~2014-06-05 22:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 22:16 [PATCH v2 0/9] Clarify two uses of remote.*.fetch Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 1/9] fetch doc: update introductory part for clarity Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 2/9] fetch doc: move FETCH_HEAD material lower and add an example Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 3/9] fetch doc: update note on '+' in front of the refspec Junio C Hamano
2014-06-18  7:56   ` Michael Haggerty
2014-06-03 22:16 ` [PATCH v2 4/9] fetch doc: remove notes on outdated "mixed layout" Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 5/9] fetch doc: on pulling multiple refspecs Junio C Hamano
2014-06-04 14:44   ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 6/9] fetch doc: update refspec format description Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 7/9] fetch doc: remove "short-cut" section Junio C Hamano
2014-06-04 14:46   ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 8/9] fetch doc: add a section on configured remote-tracking branches Junio C Hamano
2014-06-04 14:55   ` Marc Branchaud
2014-06-04 22:17     ` Junio C Hamano
2014-06-05 15:29       ` Marc Branchaud
2014-06-05 15:40         ` [PATCH] docs: Explain the purpose of fetch's and pull's <refspec> parameter Marc Branchaud
2014-06-05 22:12           ` Junio C Hamano [this message]
2014-06-11 14:24             ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 9/9] fetch: allow explicit --refmap to override configuration Junio C Hamano
2014-06-04 15:01   ` Marc Branchaud
2014-06-04 22:28     ` Junio C Hamano
2014-06-05 15:45       ` Marc Branchaud
2014-06-05 18:36         ` Junio C Hamano
2014-06-18 12:21           ` Michael Haggerty

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=xmqq61kfroow.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.