Andrew Ardill <andrew.ard...@gmail.com> writes:
> As a data point, I have seen people add ".gitignore" to their
> .gitignore file, as they don't want to share the file.
Interesting. It will break immediately when the project starts
wanting to distribute its "canonical" ignore list, but until that
time, it would "work" (for some definition of "working").
> It would be possible to check for this antipattern during normal use
> and provide a hint to the user, but that is probably too heavy handed
> and might annoy people with a legitimate use case. For that matter, if
> the gitignore file is easier to use for the 'private ignore' use case
> we have a bigger problem and shouldn't dictate to users what to use.
> ... The introduction does specifically mention 'gitignore'
> files, but that seems to be due to all the ignore files
> ($HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore) being
> classified as 'gitignore' files.
Yes. Notice that that the blanket term used is not "dot-gitignore",
but "gitignore". The difference may be too subtle, and your
suggestion to introduce a new phrase "git ignore files" as the
blanket term might be one way to make it less subtle. I would
actually think "ignore files" (without Git, as all readers know we
are talking about _our_ ignore mechanism in our documentation) may
even be a better idea.
> We could reference the multiple ignore locations earlier, for people
> who don't read past the first paragraph of to documentation.
> "Git ignore files specify intentionally untracked files that Git
> should ignore. A git ignore file can be specified for all local
> repositories, a specific local repository, or shared with other users
> of a repository. Files already tracked by Git are not affected; see
> the NOTES below for details."
Sounds good, with or without s/git ignore/ignore/.
> Finally, it's a little confusing that one of the files is called 'exclude'.
> It would be great to rename it to 'ignore'; $GIT_DIR/info/exclude ->
> $GIT_DIR/info/ignore. Is there any reason this shouldn't be done?
If we were starting Git from scratch, we may have called it
info/ignore, but we do not live in an ideal world, so we need to
worry about people's existing repositories, scripts and templates.
That does not mean we cannot transition over time, aiming to flip
the default in a future big version bump (no, not in 2.0), along the
lines of (note: I haven't thought this thru, and do not take this as
an authoritative and correct plan):
- Check if info/ignore exists, and read it without reading or
even checking the existence of info/exclude;
- Check if info/exclude exists, and read it. Warn about future
default change and tell the user to rename (or if we are
absolutely sure that we are interactive, we can offer to do the
rename for the user by prompting).
- Wait for several major releases, until major distros catch up
with step 1.
- Drop the support for info/exclude altogether, without even
warning about our stopping to read it.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html