David Kastrup <dak@xxxxxxx> writes:
> Although it would be natural to have
> core.adddirs: false
> be equivalent to
> core.excludefile: .
>
> And so it might be possible to actually not need a separate
> core.adddirs option at all, technically.
To followup on myself here:
A project such as the linux kernel which presumably does not want to
have directories tracked will put the single pattern
.
into its top-level .gitignore file. That is all. At least if it does
not confuse current versions of git to do ugly things.
A separate option core.adddirs is still necessary because
man gitignore
states:
When deciding whether to ignore a path, git normally checks gitignore
patterns from multiple sources, with the following order of precedence:
· Patterns read from the file specified by the configuration variable
core.excludesfile.
· Patterns read from $GIT_DIR/info/exclude.
· Patterns read from a .gitignore file in the same directory as the
path, or in any parent directory, ordered from the deepest such file
to a file in the root of the repository. These patterns match rela‐
tive to the location of the .gitignore file. A project normally
includes such .gitignore files in its repository, containing pat‐
terns for files generated as part of the project build.
The priority for "core.adddirs", however, should be below that so that
preferences set in the repository's .gitignore files take precedence.
So core.excludesfile seems to be the wrong place.
A project with the policy of always tracking directories would place
!.
into its top-level .gitignore file.
--
David Kastrup
-
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
