All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Lars Schneider <larsxschneider@gmail.com>,
	Brandon Williams <bmwill@google.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Submodule regression in 2.14?
Date: Fri, 18 Aug 2017 12:10:38 -0700	[thread overview]
Message-ID: <xmqqpobsbsk1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kaC-rtfp-AMdpkpCycgk568eU2y-JDGwdoSK_E=oUJo-w@mail.gmail.com> (Stefan Beller's message of "Fri, 18 Aug 2017 10:16:14 -0700")

Stefan Beller <sbeller@google.com> writes:

>> In the past "submodule.<name>.update=none" was an easy way
>> to selectively disable certain Submodules.
>>
>> How would I do this with Git 2.14?
>
>     submodule.<name>.active = false
>
>> My gut feeling is that all commands should respect the
>> "submodule.<name>.update=none" setting.
>
> Well my gut feeling was that the "update" part of the name
> reponds to the subcommand, not the generic action.
>
> For example when you set update=none, git-status,
> recursive git-diff still reported the submodule.

Both status and diff are read-only operations, so this smells like a
bit bogus argument made by comparing apples and oranges.

I think Lars is more interested in operations that actually affects
the state of submodules by updating them---"submodule update" may be
a prime example as it goes down to run fetch, pull and/or checkout.
It may have been the only thing that affected the state of
submodules before the "--recurse-submodules" option was added to
commands that affect the state of the (super)project, but I would
think that it is not so wrong to expect that these state-affecting
operations running in the "recurse into submodules" mode to honor
"do not update this submodule" that used to be honored only by
"submodule update".

  reply	other threads:[~2017-08-18 19:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 18:35 Submodule regression in 2.14? Lars Schneider
2017-08-16 18:51 ` Stefan Beller
2017-08-16 18:53   ` Stefan Beller
2017-08-17 21:21   ` Lars Schneider
2017-08-17 21:55     ` Stefan Beller
2017-08-18  2:13       ` Junio C Hamano
2017-08-18  4:02         ` Stefan Beller
2017-08-18 16:50           ` Junio C Hamano
2017-08-18 19:09             ` Stefan Beller
2017-08-19  6:51               ` Junio C Hamano
2017-08-21 16:05                 ` Heiko Voigt
2017-08-21 16:42                   ` Stefan Beller
2017-08-22 15:33                     ` Heiko Voigt
2017-08-22 18:10                       ` Stefan Beller
2017-08-25  9:10                         ` Heiko Voigt
2017-08-25 16:38                           ` Stefan Beller
2017-08-25 16:53                           ` Junio C Hamano
2017-08-21 16:48                   ` Junio C Hamano
2017-08-22 15:50                     ` Heiko Voigt
2017-08-21 16:46                 ` Stefan Beller
2017-08-21 22:45                   ` Junio C Hamano
2017-08-18 13:12       ` Lars Schneider
2017-08-18 17:16         ` Stefan Beller
2017-08-18 19:10           ` Junio C Hamano [this message]
2017-08-18 22:04             ` [PATCH] pull: respect submodule update configuration Stefan Beller
2017-08-18 22:05               ` Stefan Beller
2017-08-19  6:17                 ` Junio C Hamano
2017-08-19  6:24               ` Junio C Hamano
2017-08-21 16:20                 ` Heiko Voigt
2017-08-21 16:55                   ` Stefan Beller
2017-08-21 17:20                     ` Lars Schneider
2017-08-21 17:48                       ` Stefan Beller
2017-08-21 18:21                         ` Brandon Williams
2017-08-21 22:52                           ` Junio C Hamano
2017-08-22 14:50                           ` Lars Schneider
2017-08-22 17:51                             ` Stefan Beller
2017-08-22 18:55                               ` Brandon Williams
2017-08-19 18:24           ` Submodule regression in 2.14? Lars Schneider

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=xmqqpobsbsk1.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=sbeller@google.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.