Re: [PATCH v3 0/3] submodule: port subcommand add from shell to C

Shourya Shukla <periperidip@gmail.com> writes:

Let me rephrase. When a user has "[submodule] active" in his or her configuration file, it is a configuration error. When Git reads "submodule.active" configuration variable to make a decision (like the above code) and finds that the user has such an error, the user would appreciate if the error is pointed out, so that it can be corrected, rather than silently ignored.

Makes me wonder if I am getting the semantics of submodule.active variable right.

From the three-line description in the documentation (see above), I would have guessed that if we have three values for submodule.active, e.g.

	[submodule]
		active = $a
		active = $b
		active = $c

then when deciding if we want to see if a submodule at a $sm_path, we'd see if $path matches any one of $a, $b, or $c and if it does, it is determined that the submodule is "of interest to git commands".

Yes, we may be fetching information only about one submodule at $sm_path, but given the explanation of how the configuration variable is designed to work, how can we _not_ fetch the list and check all of them?

So the comment above (for that matter, the one below that talks about valuless true) does not make any sense to me, sorry.

The real reason why it is OK to just check existence of submodule.active variable without seeing any value of them is because the check is done to see if this call is needed at all:

	git submodule--helper is-active "$sm_path"

This "helper" eventually calls submodule.c::is_submodule_active() that does the real check---it gets the multi-valued submodule.active and checks them against the path to determine if the submodule is "of interest".

On the other hand, when we know submodule.active does not exist, all submodules are of interest when it comes to "submodule add". That is how

- if git config --get submodule.active >/dev/null - then - # If the submodule being adding isn't already covered by the - # current configured pathspec, set the submodule's active flag - if ! git submodule--helper is-active "$sm_path" - then - git config submodule."$sm_name".active "true" - fi - else - git config submodule."$sm_name".active "true" - fi

taken from your [2/3] that ignored the values of submodule.active is "correct"; we know that the real work is done elsewhere--we are only learning if the is-active check is necessary.

I think explaining why it works correctly to show future readers that the code was written by folks who knew what they were doing would be worth the effort to help future code evolution.

This, from your [1/3], is a faithful translation of the above, but ...

+ if (!git_config_get_string("submodule.active", &var) && var) { + + /* + * If the submodule being adding isn't already covered by the + * current configured pathspec, set the submodule's active flag + */ + if (!is_submodule_active(the_repository, info->sm_path)) { + key = xstrfmt("submodule.%s.active", info->sm_name); + git_config_set_gently(key, "true"); + free(key); + } + } else { + key = xstrfmt("submodule.%s.active", info->sm_name); + git_config_set_gently(key, "true"); + free(key); + }

... by knowing why we check submodule.active but discard its value, future developers (read: I think this is outside the scope of this series) can rewrite it like so to make it more readable and reduce the repeated code to set submodule.$sm_name.active to true.

        /*
	 * If submodule.active does not exist, we will activate this
	 * module unconditionally.
	 *
         * Otherwise, is_submodule_active() is asked to determine if
         * the path currently is of interest; because it will obtain
         * and iterate over this multi-valued variable by itself, we
         * do not need its values we obtain from git_config_get_string()
         * call here.  We are only checking if we need to ask the
         * is_submodule_active() helper function.  We explicitly set
	 * the submodule.$sm_name.active if submodule.active patterns
	 * do not cover the path (i.e. is_submodule_active() says "no".
         */
	if (git_config_get_string("submodule.active", &var) ||
	    !is_submodule_active(the_repository, info->sm_path)) {
		key = xstrfmt(...);
		git_config_set_gently(key, "true");
		free(key);
	}

and a comment like this would help such readers, for example.

By the way, as you might have noticed, your [1/3] contains a lot of material that ought to be part of [2/3], doesn't it? [1/3] was supposed to be just borrowing helper from dir.c but has the new "add" code implemented in the same patch.

I'll leave the other two to other reviewers and mentors for now, but may come back to them if I beat them.

Thanks.