git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	Heiko Voigt <hvoigt@hvoigt.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] push: change submodule default to check
Date: Tue, 4 Oct 2016 10:48:51 -0700	[thread overview]
Message-ID: <CAGZ79kaKOjqLBsNVSmudzLUCkOJf_CsFGE8OZZHsTmuXCfiVeg@mail.gmail.com> (raw)
In-Reply-To: <20161004173430.eax4ptohyonc5bw2@sigill.intra.peff.net>

On Tue, Oct 4, 2016 at 10:34 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 04, 2016 at 09:40:36AM -0700, Stefan Beller wrote:
>
>> >> Why should we even have a default different from today's?  If most
>> >> repositories don't have submodules enabled at all, we can just let
>> >> those working with submodules enabled to toggle their configuration
>> >> and that is an very easy to understand solution, no?
>> >
>> > You will not see any complaint from me on that. I was taking for granted
>> > that the current default is inconvenient to submodule users, but I don't
>> > have any experience myself.
>> >
>>
>> And there I was trying to help submodule users not shoot in their foot.
>
> Sorry if my reply came off as snarky.

Yeah, sorry about starting being snarky here.

>>
>> +static void preset_submodule_default(void)
>> +{
>> +     if (file_exists(".gitmodules"))
>> +             recurse_submodules = RECURSE_SUBMODULES_CHECK;
>> +     else
>> +             recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
>> +}
>
> This does seem like a reasonable heuristic. I wonder if you want to
> confirm that we actually have a worktree (and are in it) before looking
> at file_exists(). It's unlikely that looking at ".gitmodules" in a bare
> repo would trigger in practice, but it does not hurt to be careful.

In a bare repo we'd rather want to check for an entry of .gitmodules in HEAD ?

I considered it a non issue, as I don't think many people push from
bare repositories.
So if we were to check in the HEAD tree instead of the file system, why would we
apply different rules for bare and non bare repositories? We probably
would not want
to do that, so is it reasonable to check for the .gitmodules in the HEAD tree in
general in the non bare case? I dunno, it sounds like an equally cheap heuristic
covering most cases.

Here is another thought:
.gitmodules may not exist (either in working dir or in HEADs git
tree), so maybe the
"correct" heuristic is to check for directories in $GIT_DIR/modules/
That is "more correct", because it is inconceivable to change the submodule
pointers without having the submodules checked out. (Who would do that? Why?)

>
> -Peff

  reply	other threads:[~2016-10-04 17:49 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-03 21:11 Slow pushes on 'pu' - even when up-to-date Linus Torvalds
2016-10-03 21:17 ` Stefan Beller
2016-10-03 21:23   ` Stefan Beller
2016-10-03 22:06     ` Junio C Hamano
2016-10-04 11:18 ` Heiko Voigt
2016-10-04 11:44   ` Jeff King
2016-10-04 12:04     ` Heiko Voigt
2016-10-04 12:07       ` Jeff King
2016-10-04 16:19     ` Junio C Hamano
2016-10-04 16:21       ` Jeff King
2016-10-04 16:40         ` [PATCH] push: change submodule default to check Stefan Beller
2016-10-04 17:34           ` Jeff King
2016-10-04 17:48             ` Stefan Beller [this message]
2016-10-04 17:54               ` Jeff King
2016-10-04 18:04                 ` Junio C Hamano
2016-10-04 18:08                   ` Stefan Beller
2016-10-04 18:28                     ` Jeff King
2016-10-04 19:29                       ` [PATCHv2 1/2] push: change submodule default to check when submodules exist Stefan Beller
2016-10-04 19:29                         ` [PATCH 2/2] builtin/push: move flags do_push Stefan Beller
2016-10-04 19:39                         ` [PATCHv2 1/2] push: change submodule default to check when submodules exist Jeff King
2016-10-04 19:51                           ` Stefan Beller
2016-10-04 21:03                             ` [PATCHv3 " Stefan Beller
2016-10-05 13:53                               ` Heiko Voigt
2016-10-06  9:23                                 ` Heiko Voigt
2016-10-06 17:20                                   ` Stefan Beller
2016-10-07 12:41                                     ` Heiko Voigt
2016-10-05 15:47                               ` Jeff King
2016-10-05 15:54                                 ` Stefan Beller
2016-10-04 18:00           ` [PATCH] push: change submodule default to check Junio C Hamano
2016-10-04 18:02             ` Junio C Hamano
2016-10-04 18:05             ` Stefan Beller
  -- strict thread matches above, loose matches on Subject: below --
2016-08-17 20:48 Stefan Beller
2016-08-17 21:05 ` Junio C Hamano
2016-08-17 21:14   ` Stefan Beller
     [not found]     ` <20160818140922.GA5925@sandbox>
2016-08-24 16:46       ` Stefan Beller
2016-08-24 18:08         ` Junio C Hamano

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=CAGZ79kaKOjqLBsNVSmudzLUCkOJf_CsFGE8OZZHsTmuXCfiVeg@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.org \
    /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).