Junio C Hamano <gitster@xxxxxxxxx> writes: > Elijah Newren <newren@xxxxxxxxx> writes: > > > I suspect we're having an aliasing problem that you're not > > recognizing. "ignored" and "excluded" are used interchangeably, note > > that patterns from the $GIT_DIR/info/exclude files and patterns from > > the file pointed to by core.excludesFile are also lumped together with > > the patterns from all the .gitignore files (see the gitignore manual > > page). Further, the internal code refers to them all as "excludes" > > not as "ignores". > > All true. I wasn't surprised that 'ignoread' and 'excluded' are used interchangably, that's not the problem. > > Yes, it outputs the paths that are excluded, as the documentation > > said. Perhaps there's a way to reword it to make this clearer? I > > don't think we can get rid of the alias given the fact that > > $GIT_DIR/info/exclude and core.excludesFile are hard-coded and must be > > kept for backward compatibility. But suggestions to improve the > > wording would be great. > > > > Maybe it'd be as simple as replacing "is excluded" with "matches an > > ignore/exclude rule"? > > I smell a continuation of 7ec8125f (check-ignore: fix documentation > and implementation to match, 2020-02-18), which appears in 2.26 and > later (the way the negative entries in the ignore/exclude mechanism > gets handled has changed in Git 2.26, and the documentation has been > updated). > > "Is excluded" is perfectly fine, I think. The first use of that > verb in the documentation should be a bit more careful, e.g. "is > excluded (aka ignored)" or something. I think replacing with "matches an ignore/exclude rule" is prefereable since that's what's actually going on. It's still a bit unfortunate since the ignore/exclude terms are potentially confusing in the presence of dont-ignore (!) rules, but it seems likely that people running check-ignore are looking to sort out something complicated and are probably aware of negative rules, and anyway they get a ! to clue them in :) Adding some explanation to the first use of "excluded" would in principle solve the problem by itself and give licence to use the term however you want, but to be honest I'm not sure I would have read that paragraph carefully enough to get the idea. It still seems better to me to use different language each time it comes up in the page. > >> IMO the behavior of git-check-ignore is the correct and useful > >> behavior > > > > I'm with you here. > > Yup, with the old "huh?" fixed in Git 2.26 (which was there simply > because check-ignore was not used to be a serious end-user facing > program but was more of a debugging aid), I think the behaviour of > the command we have today is what we want. > > >> and the documentation should simply be fixed > > > > Yes, I agree it's easy to misinterpret. Would my suggested changes help? > > > >> to reflect the > >> fact that it just lists matching entries rather than wrongly claiming > >> that it returns the overall result of the ignore calculation. > > > > I think I understood where the problems were in the documentation that > > could lead to misinterpretations in the other two cases you mentioned > > earlier in your email, but I don't understand this one. Even the > > first sentence you quoted included the phrase that it could "output > > the path", so I'm not sure where you think it claims that it'd return > > the overall result of the ignore calculation. Could you point out > > what in the document led you to believe it was claiming this? Maybe I > > could suggest wording improvements for it as well. Or maybe you have > > some. > > It does return *the* matching entry that decided the path's fate. > > $ (echo '/no-such-*'; echo '!/no-such-*') >>.git/info/exclude > $ git check-ignore -v no-such-directory; echo $? > .git/info/exclude:14:!/no-such-* no-such-directory > 0 Good point: it's not exactly a full query either. If it would be welcome and hasn't already been done I could rewrite this page to be clearer without adding or changing much. Britton
