Jameson Miller <jameson.miller81@xxxxxxxxx> writes: >>> +If this is set, files and directories that explicity match an ignore >>> +pattern are reported. Implicity ignored directories (directories that >>> +do not match an ignore pattern, but whose contents are all ignored) >>> +are not reported, instead all of the contents are reported. >> Makes me wonder if DIR_SHOW_IGNORED* should be splt out into a short >> enum. We have: >> >> - Do not show ignored ones (0) >> >> - Collect ignored ones (DIR_SHOW_IGNORED) >> >> - Collect ignored and untracked ones separately (DIR_SHOW_IGNORED_TOO) >> >> - Collect ignored and duntracked ones separately, but limit them to >> those mach exclude patterns explicitly (DIR_SHOW_IGNORED_TOO|...MODE_MATCHING) >> >> so we need two bits to fit a 4-possiblity enum. >> >> Then we do not have to worry about saying quirky things like A and B >> are incompatible, and C makes sense only when B is set, etc. > I could see a potential for other values for the "show ignored > mode" flags - for example: "NORMAL", "MATCHING", "ALL"... Instead > of making more change at this point in time, how would you feel > about waiting until the next change in this area. > > If you would prefer for me to change these enums now, I can do > that. "Makes me wonder" was just that. I was made to wonder. I did not have strong opinions either way. You thought about the area of this code longer than I did, so I do not mind you picking the course of action that is best for the project, and if you think it is better to wait until we know more about the vocabulary we want to support before we restructure these flags, that is fine by me. Thanks.
