On 18. 4. 2014 14:28, Jens Lehmann wrote:
> Am 13.04.2014 01:41, schrieb Ronald Weiss:
>> Second, there are some differences between adding standard ignored
>> files, and ignored submodules:
>>
>> 1) Already tracked files are never ignored, regardless of .gitignore.
>> However, tracked submodules should be ignored by "add -u", if told so
>> by their ignore setting.
>>
>> 2) So .gitignore seems to only do something when adding new files to
>> the repo. However, when adding new submodules, they are probably never
>> ignored (setting the ignore setting for non existent submodule seems
>> like non-sense, although possible).
>
> What about "diff.ignoreSubmodules=all"?
>
>> 3) Ignored files can be ignored less explicitely (in global gitignore,
>> or using a wildcard, or by ignoring parent folder). So it makes sense
>> to warn the user if he tries to explicitely add an ignored file, as he
>> might not be aware that the file is ignored. Submodules, however, can
>> only be ignored explicitely. And when user explicitely specifies the
>> submodule in an add command, he most probably really wants to add it,
>> so I don't see the point in warning him and requiring the -f option.
>
> But we do have "diff.ignoreSubmodules=all", so I do not agree with
> your conclusion.
Ah, I didn't know about diff.ignoreSubmodules. I agree that it defeats
two of my points :-(.
And how about the point 1), should submodules never be ignored once
already tracked, like standard ignored files? I'm almost sure that in
this case the behavior should be different, otherwise it would drop
the most useful use case of the proposed change.
>> So, I think that the use cases are completely different, for submodules
>> and ignored files. So trying to make add behave the same for both, might
>> not be that good idea.
>>
>> I would propose - let's make add honor the ignore setting by just
>> parsing if from config like the other commands do, and pass it to
>> underlying diff invocations. And at the same the, let's override it for
>> submodules explicitely specified on the command line, to never ignore
>> such submodules, without requiring the -f option. That seems to be
>> pretty easy, see below.
>
> What about doing that only when '-f' is given? Would that do what we
> want?
OK then, seems right with diff.ignoreSubmodules in mind.
But one question stays - what to do with submodules not explicitly
specified on command line (when their parent folder is being added)?
You adviced already to do what we do with standard ignored files. That
seems to be:
A) if the file is already tracked, add it
B) if not tracked, without -f, silently ignore it
C) if not tracked, with -f, add it
A) is same like point 1 above, let's forget it until we settle that one.
But B) is even more problematic, we would probably have to modify the
directory parsing code in dir.c to handle ignored submodules. Is that
what we want? If so, then I'm afraid this is getting overly complicated.
>> @@ -320,6 +324,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>> char *seen = NULL;
>>
>> git_config(add_config, NULL);
>> + gitmodules_config();
>
> Wrong order, gitmodules_config() must be called before git_config()
> to make the .gitmodules settings overridable by the users config.
Right. I noticed that too just after sending the patch.
>> @@ -440,6 +446,18 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>> die(_("pathspec '%s' did not match any files"),
>> pathspec.items[i].original);
>> }
>> +
>> + /* disable ignore setting for any submodules specified explicitly in the pathspec */
>> + if (path[0] &&
>> + (cachepos = cache_name_pos(path, pathspec.items[i].len)) >= 0 &&
>> + S_ISGITLINK(active_cache[cachepos]->ce_mode)) {
>> + char *optname;
>> + int optnamelen = pathspec.items[i].len + 17;
>> + optname = xcalloc(optnamelen + 1, 1);
>> + snprintf(optname, optnamelen + 1, "submodule.%s.ignore", path);
>> + parse_submodule_config_option(optname, "none");
>
> We should use "dirty" instead of "none" here. Modifications inside
> the submodule cannot be added without committing them there first
> and using "none" might incur an extra preformance penalty for
> looking through the submodule directories for such changes.
OK, that's right too.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html