git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Stefan Beller <sbeller@google.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.
Date: Sat, 21 Jan 2017 19:55:05 +0700	[thread overview]
Message-ID: <CACsJy8DJpueeRqLSbGuY6gsMKeYd+Q0dUzFB4p_Sq-795MhG1A@mail.gmail.com> (raw)
In-Reply-To: <20170120191728.l3ne5tt5pwbmafjh@sigill.intra.peff.net>

On Sat, Jan 21, 2017 at 2:17 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote:
>
>> Now let's ask the same question for "git -C sub status ." (which is a
>> command that is only reading and not writing to the repository)
>>
>> 1) If the submodule is populated, the user clearly intended to know
>>    more about the submodules status
>> 2) It is unclear if the user wanted to learn about the submodules state
>>    (So ideally: "The submodule 'sub' is not initialized. To init ...")
>>    or the status check should be applied to the superproject instead.
>>
>> Avoid the confusion in 2) as well and just error out for now. Later on
>> we may want to add another flag to git.c to allow commands to be run
>> inside unpopulated submodules and each command reacts appropriately.
>
> I like the general idea of catching commands in unpopulated submodules,
> but I'm somewhat uncomfortable with putting an unconditional check into
> git.c, for two reasons:
>
>   1. Reading the index can be expensive. You would not want "git
>      rev-parse" to incur this cost.
>
>   2. How does this interact with commands which do interact with the
>      index? Don't they expect to find the_index unpopulated?
>
>      (I notice that it's effectively tied to RUN_SETUP, which is good.
>       But that also means that many commands, like "diff", won't get the
>       benefit. Not to mention non-builtins).
>
> I'd rather see it in the commands themselves. Especially given the
> "ideal" in your status example, which requires command-specific
> knowledge.

I agree. It's already bad enough for pathspec code to peek into the
index, adding a hidden dependency between parse_pathspec() and
read_cache(). And I still think parse_pathspec() is not the right
place to check submodule paths. Worktree should be checked as well, in
the case that the submodule is not yet registered in the index. The
right place to do that is per-command, with their consent so to speak,
because they may need to set things up (index, .git/config and stuff)
properly before explicitly doing this check.
-- 
Duy

      parent reply	other threads:[~2017-01-21 12:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-19 19:30 [RFC/PATCH] Disallow commands from within unpopulated submodules Stefan Beller
2017-01-20 19:17 ` Jeff King
2017-01-20 19:33   ` Stefan Beller
2017-01-20 19:42     ` Jeff King
2017-01-20 19:53       ` Stefan Beller
2017-01-20 20:00         ` Jeff King
2017-01-20 20:07           ` Stefan Beller
2017-01-20 21:41           ` Junio C Hamano
2017-01-20 21:48             ` Jeff King
2017-01-20 21:58             ` Junio C Hamano
2017-01-20 22:01               ` Jeff King
2017-01-20 23:22               ` Stefan Beller
2017-01-21 12:55   ` Duy Nguyen [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

  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=CACsJy8DJpueeRqLSbGuY6gsMKeYd+Q0dUzFB4p_Sq-795MhG1A@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --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.
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).