git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
	git@vger.kernel.org
Subject: Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables
Date: Fri, 16 Jun 2017 23:10:43 +0200	[thread overview]
Message-ID: <87vanv8wq4.fsf@gmail.com> (raw)
In-Reply-To: <20170616204109.GB133952@aiede.mtv.corp.google.com>


On Fri, Jun 16 2017, Jonathan Nieder jotted:

> Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 16 2017, SZEDER Gábor jotted:
>
>>> --- a/Documentation/git-clone.txt
>>> +++ b/Documentation/git-clone.txt
>>> @@ -186,6 +186,11 @@ objects from the source repository into a pack in the cloned repository.
>>>  	values are given for the same key, each value will be written to
>>>  	the config file. This makes it safe, for example, to add
>>>  	additional fetch refspecs to the origin remote.
>>> ++
>>> +Due to limitations if the current implementation, some configuration
>>> +variables do not take effect until after the initial fetch and checkout.
>>> +Configuration variables known to not take effect are:
>>> +`remote.<name>.mirror` and `remote.<name>.tagOpt`.
>>>
>>>  --depth <depth>::
>>>  	Create a 'shallow' clone with a history truncated to the
> [...]
>> But this is now cooking in pu, Junio: is it clear that this patchu
>> as-cooking ideally shouldn't land in next/master without the fix on top
>> which I mentioned in my mail above? I can just submit that as a patch on
>> top, but I'm confused about the current state with this cooking in pu,
>> so I thought I'd ask first how this should be handled.
>
> I think it's simplest to write a patch on top that discusses --no-tags.
> That way, Junio (and anyone else applying the patch) has the
> flexibility to apply or cherry-pick this change to old branches
> without the --no-tags discussion and newer branches with it.
>
> Would you like to write it (or suggest wording), or would you prefer
> if someone else does?

I can do that no problem.

I just first wanted to clarify what the status of this was, from
SZEDER's comments in the referenced E-Mails I had the impression that
this was only meant for an old maintenance release:

    SZEDER: "I assume because, as a bugfix, it will be included in
    maintenance releases for older releases, and those won't have the
    '--no-tags' option."

But thinking about it I don't see why we'd be doing such minor doc
changes in an old maintenance release. I haven't read the whole backlog
of this topic though, so maybe I missed something.

I initially suggested just adding "Instead supply the --mirror and
--no-tags options, respectively" to the patch quoted above.

But actually, thinking about this again now, and being recently familiar
with this code after having implemented  on --no-tags, I think this
whole wording is just misleading. It makes it sound as though git clone
is init + fetch, and that the initial fetch just ignores these two
specific options because of some quirk of the implementation.

In reality clone doesn't use fetch at all, they just share some of the
underlying fetch machinery.

I think something like this as a replacement is better, assuming this
really needs to be applied to pre-2.13.0:

    diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
    index 35cc34b2fb..2169e5c97f 100644
    --- a/Documentation/git-clone.txt
    +++ b/Documentation/git-clone.txt
    @@ -189,6 +189,14 @@ objects from the source repository into a pack in the cloned repository.
            values are given for the same key, each value will be written to
            the config file. This makes it safe, for example, to add
            additional fetch refspecs to the origin remote.
    ++
    +The underlying implementation of `git clone` isn't equivalent to `git
    +init` followed by a `git fetch`, but the two share some of the
    +underlying fetch machinery. Because of this, setting configuration
    +variables which would impact `git fetch` doesn't have any effect on
    +`git clone` at all. For example, setting `remote.<name>.mirror` and
    +`remote.<name>.tagOpt` will do to change how the initial fetch is
    +carried out.

     --depth <depth>::
            Create a 'shallow' clone with a history truncated to the

Or, in case this just needs to be applied on top of master we can
mention --no-tags:

    diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
    index 83c8e9b394..52a371176e 100644
    --- a/Documentation/git-clone.txt
    +++ b/Documentation/git-clone.txt
    @@ -189,6 +189,16 @@ objects from the source repository into a pack in the cloned repository.
            values are given for the same key, each value will be written to
            the config file. This makes it safe, for example, to add
            additional fetch refspecs to the origin remote.
    ++
    +The underlying implementation of `git clone` isn't equivalent to `git
    +init` followed by a `git fetch`, but the two share some of the
    +underlying fetch machinery. Because of this, setting configuration
    +variables which would impact `git fetch` doesn't have any effect on
    +`git clone` at all.
    ++
    +For example, setting `remote.<name>.mirror` and `remote.<name>.tagOpt`
    +will do to change how the initial fetch is carried out. Instead supply
    +the --mirror and --no-tags options, respectively.

     --depth <depth>::
            Create a 'shallow' clone with a history truncated to the

  reply	other threads:[~2017-06-16 21:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 11:05 [PATCHv3 0/4] clone: respect configured fetch respecs during initial fetch SZEDER Gábor
2017-05-15 11:05 ` [PATCHv3 1/4] clone: respect additional configured fetch refspecs " SZEDER Gábor
2017-05-15 23:07   ` Jeff King
2017-05-26 10:04     ` SZEDER Gábor
2017-05-26 13:30       ` Jeff King
2017-05-30  3:53         ` Junio C Hamano
2017-05-30  3:55           ` Jeff King
2017-05-30  7:11           ` SZEDER Gábor
2017-05-30  7:12             ` [PATCHv4 1/2] " SZEDER Gábor
2017-05-30  7:12               ` [PATCHv4 2/2] Documentation/clone: document ignored configuration variables SZEDER Gábor
2017-05-30  9:01                 ` Ævar Arnfjörð Bjarmason
2017-05-31  8:50                   ` SZEDER Gábor
2017-05-31 14:17                     ` Ævar Arnfjörð Bjarmason
2017-06-13 23:24                 ` Jonathan Nieder
2017-05-31  4:23               ` [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch Jeff King
2017-05-31  9:34                 ` SZEDER Gábor
2017-06-05  8:18                   ` Jeff King
2017-06-06 18:19                     ` SZEDER Gábor
2017-06-06 18:37                       ` Jeff King
2017-06-07 11:17                         ` SZEDER Gábor
2017-06-14  0:48               ` Jonathan Nieder
2017-06-14  9:50                 ` Jeff King
2017-06-16 17:36                 ` SZEDER Gábor
2017-06-16 17:38                   ` [PATCHv5 0/2] " SZEDER Gábor
2017-06-16 17:38                     ` [PATCHv5 1/2] " SZEDER Gábor
2017-06-16 20:37                       ` Jonathan Nieder
2017-06-17 11:22                       ` Jeff King
2017-06-22 22:23                         ` Junio C Hamano
2017-08-12  0:48                           ` Junio C Hamano
2017-06-16 17:38                     ` [PATCHv5 2/2] Documentation/clone: document ignored configuration variables SZEDER Gábor
2017-06-16 18:23                       ` Ævar Arnfjörð Bjarmason
2017-06-16 20:41                         ` Jonathan Nieder
2017-06-16 21:10                           ` Ævar Arnfjörð Bjarmason [this message]
2017-06-16 22:15                             ` SZEDER Gábor
2017-06-16 20:38                       ` Jonathan Nieder
2017-06-16 22:09                       ` Junio C Hamano
2017-05-31  4:27             ` [PATCH] remote: drop free_refspecs() function Jeff King
2017-06-14  0:49               ` Jonathan Nieder
2017-05-15 11:05 ` [PATCHv3 2/4] Documentation/clone: document ignored configuration variables SZEDER Gábor
2017-05-26 14:01   ` SZEDER Gábor
2017-05-15 11:05 ` [PATCHv3 3/4] remote: drop free_refspecs() function SZEDER Gábor
2017-05-15 11:05 ` [PATCHv3 4/4] clone: use free_refspec() to free refspec list SZEDER Gábor
2017-05-15 11:29   ` SZEDER Gábor
2017-05-15 23:10     ` Jeff King
2017-05-23  7:38     ` Junio C Hamano
2017-05-23 11:27       ` Jeff King
2017-05-23 12:06       ` SZEDER Gábor
2017-05-15 22:46 ` [PATCHv3 0/4] clone: respect configured fetch respecs during initial fetch Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vanv8wq4.fsf@gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=szeder.dev@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).