git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael Ascensão" <rafa.almas@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Marius Giurgi" <marius.giurgi@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Michael Haggerty" <mhagger@alum.mit.edu>
Subject: Re: [RFC PATCH 1/2] docs: reflect supported fetch options of git pull
Date: Tue, 5 Jun 2018 21:46:07 +0100	[thread overview]
Message-ID: <20180605204607.GA4679@rigel> (raw)
In-Reply-To: <CACsJy8DVi0rqjw0dCdxppb=e+jH5yNcX9XcRXDnvLXS8x0QsJA@mail.gmail.com>

On Tue, Jun 05, 2018 at 06:05:56PM +0200, Duy Nguyen wrote:
> A better option may be making git-pull accept those options as well. I
> see no reason git-pull should support options that git-fetch does (at
> least most of them).

I sent this as a RFC, mostly to discuss what is the correct path to
follow. Updating the documentation was trivial and would still be useful
if nothing came out from this.

> It's basically a couple of OPT_PASSTRHU though so not very hard to do.

My impression was that in the past git was very permissive on adding new
options but nowadays it tries exercise more restraint. But not sure how
relevant this is anyways, as pull already supports the majority of the
options from both `fetch` and `merge`.

> PS. Anybody up to making parse-options accept multiple struct option
> arrays? This way we can have much better option passthru without
> specifying them again and again.

If the path is adding just couple of OPT_PASSTRHU, I could do it. But
I'll wait and see if someone picks your parse-options suggestion.

Thanks for the review.

--
Rafael Ascensão

      reply	other threads:[~2018-06-05 20:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-04 21:50 [RFC PATCH 1/2] docs: reflect supported fetch options of git pull Rafael Ascensão
2018-06-04 21:50 ` [RFC PATCH 2/2] pull: allow -e as a synonym for --edit Rafael Ascensão
2018-06-05 16:05 ` [RFC PATCH 1/2] docs: reflect supported fetch options of git pull Duy Nguyen
2018-06-05 20:46   ` Rafael Ascensão [this message]

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=20180605204607.GA4679@rigel \
    --to=rafa.almas@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=marius.giurgi@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).