On Fri, Jan 31, 2020 at 10:04 AM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > > On Wed, Jan 29, 2020 at 10:03:40PM +0000, Elijah Newren via GitGitGadget wrote: > > From: Elijah Newren <newren@xxxxxxxxx> > > > > Despite having contributed several fixes in this area, I have for months > > (years?) assumed that the "exclude" variable was a directive; this > > caused me to think of it as a different mode we operate in and left me > > confused as I tried to build up a mental model around why we'd need such > > a directive. I mostly tried to ignore it while focusing on the pieces I > > was trying to understand. > > > > Then I finally traced this variable all back to a call to is_excluded(), > > meaning it was actually functioning as an adjective. In particular, it > > was a checked property ("Does this path match a rule in .gitignore?"), > > rather than a mode passed in from the caller. Change the variable name > > to match the part of speech used by the function called to define it, > > which will hopefully make these bits of code slightly clearer to the > > next reader. > > Slightly related questions: Does 'excluded' always mean ignored? Or > is it possible for a file to be excluded but for some other reason > than being ignored? > > I'm never really sure, and of course it doesn't help that we have both > '.gitignore' and '.git/info/exclude' files and conditions like: > > > + if (excluded && > > + (dir->flags & DIR_SHOW_IGNORED_TOO) && > > + (dir->flags & DIR_SHOW_IGNORED_TOO_MODE_MATCHING)) { > Good question; no idea. You can start digging into is_excluded() and the pattern list stored in the dir struct and try to trace it back to see if it's just the combination of ignore rules in .gitignore and .git/info/exclude and core.excludesFile, or if there is something else meant here.