All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: git@vger.kernel.org, Rose Kunkel <rose@rosekunkel.me>,
	Emily Shaffer <emilyshaffer@google.com>,
	Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH] submodule: mark submodules with update=none as inactive
Date: Fri, 25 Jun 2021 23:02:57 +0000	[thread overview]
Message-ID: <YNZgoS9R1qam+62C@camp.crustytoothpaste.net> (raw)
In-Reply-To: <56b5c722-8baf-9f9c-cc9f-5b5ed49d7fc3@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

On 2021-06-22 at 03:45:45, Philippe Blain wrote:
> > That will make us properly ignore the submodule
> > when performing recursive operations.
> > 
> > Note that we only do this when the --require-init option is passed,
> > which is only passed during clone.  That's because the update-clone
> > submodule helper is also invoked during a user-invoked git submodule
> > update, where we explicitly indicate that we override the configuration
> > setting, so we don't want to set such a configuration option then.
> 
> I'm not sure what you mean here by 'where we explicitely indicate that we
> override the configuration setting'. For me, as I wrote above,
> 'git clone --recurse-submodules' and 'git clone' followed by
> 'git submodule update --init' should lead to mostly [*] the same end result.
> 
> If you mean 'git submodule update --checkout', that indeed seems to sometimes override the 'update=none'
> configuration (a fact which is absent from the documentation), then it's true that we
> would not want to write 'active=false' at that invocation. As an aside, in my limited testing
> I could not always get 'git submodule update --checkout' to clone and checkout 'update=none' submdules;
> it would fail with "fatal: could not get a repository handle for submodule 'sub1'" because
> 'git checkout/reset --recurse-submodules' leaves a bad .git/modules/sub1/config file
> with the core.worktree setting when the command fails (this should not happen)...

Yes, that's what I meant.

> In any case, that leads me to think that maybe the right place to write the 'active' setting
> would be during 'git submodule init', thus builtin/submodule--helper.c::init_submodule ?
> This way it would lead to the same behaviour if the clone was recursive or not,
> and it would not interfere with 'git submodule update --checkout'.

Let me take a look at some other approaches and see if I can come up
with something a little bit better.

My apologies for the delay in response; I'm in the process of moving at
the moment and my attention has been directed elsewhere than the list.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2021-06-25 23:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16  0:16 [BUG] `git reset --hard` fails with `update = none` submodules Rose Kunkel
2021-06-16  0:51 ` brian m. carlson
2021-06-16  0:57   ` Rose Kunkel
2021-06-16  1:03     ` Rose Kunkel
2021-06-16  1:15       ` Rose Kunkel
2021-06-16  1:25       ` brian m. carlson
2021-06-16  1:39         ` Rose Kunkel
2021-06-16  1:46           ` Rose Kunkel
2021-06-16  3:10         ` Junio C Hamano
2021-06-16 13:20           ` Philippe Blain
2021-06-17 23:52             ` brian m. carlson
2021-06-19 21:44               ` [PATCH] submodule: mark submodules with update=none as inactive brian m. carlson
2021-06-22  3:45                 ` Philippe Blain
2021-06-25 23:02                   ` brian m. carlson [this message]
2021-06-26 15:12                     ` Philippe Blain
2021-07-01 22:51               ` [PATCH v2] " brian m. carlson
2021-07-09 20:26                 ` Philippe Blain
2021-07-11 16:59                   ` brian m. carlson

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=YNZgoS9R1qam+62C@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=rose@rosekunkel.me \
    /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.