On Tue, Oct 04, 2016 at 12:29:09PM -0700, Stefan Beller wrote:

> Jeff wrote:
> > Consulting .git/config is fine, I think. It's not like we don't read it
> > (sometimes multiple times!) during the normal course of the program
> > anyway. It's just a question of whether it makes more sense for the
> > heuristic to kick in after "init", or only after "update". I don't know
> > enough to have an opinion.
> 
> I think there is no difference in practice, however the "after update"
> is way easier to implement and hence more maintainable (one lstat instead of
> fiddeling with the config; that can go wrong easily). 

Hmm, I would have thought it is the opposite; can't submodules exist in
the working tree in their own ".git" directory? I know that's the "old"
way of doing it, but I didn't know if it was totally deprecated.

Anyway, the config version is probably just:

  int config_check_submodule(const char *var, const char *value, void *data)
  {
        if (starts_with(var, "submodule.") && ends_with(var, ".path"))
                *(int *)data = 1;
        return 0;
  }

  ...
  int have_submodule = 0;
  git_config(config_check_submodule, &have_submodule);

But I don't care too much either way. that's just for reference.

> @@ -31,6 +32,19 @@ static const char **refspec;
>  static int refspec_nr;
>  static int refspec_alloc;
>  
> +static void preset_submodule_default(void)
> +{
> +     struct strbuf sb = STRBUF_INIT;
> +     strbuf_addf(&sb, "%s/modules", get_git_dir());
> +
> +     if (file_exists(sb.buf))

Maybe just:

  if (file_exists(git_path("modules"))

?

-Peff

Reply via email to