On 15/04/29, Robert P. J. Day wrote: > some (hopefully) trivial questions about .gitignore, since the > actual documentation isn't as precise as it could be. as examples, i'm > going to use the top-level .gitignore file that comes with the kernel > source tree, since it seems that that file could be clearer. > > from the first part of the file: > > .* > *.o > *.o.* > *.a > *.s > *.ko > *.so > ... snip ... > > that first rule would seem to specify that all objects (file or > directory) that begin with a dot are to be ignored, which is fine. > after that, we get into more specific wildcards and, first question, > generic patterns like that will be applied in that directory and all > sub-directories, correct? (barring any sub-directories negating it). Almost certainly. > next question -- a pattern will apply to *any* file type (file or > directory), unless suffixed with a slash, whereupon it will apply only > to a directory, yes? this would appear to be the case since the kernel > .gitignore contains the following lines: > > /vmlinux > /System.map > ... > /debian/ > /tar-install/ I assume the "/" prefix anchors it in the root of the git tree... > the first two above being files, the second two obviously being > directories. if, however, i had specified just: > > /debian > > i am assuming it would still work (barring the unusual existence of a > top-level file named "debian", of course). > > given that, these few lines in the file seem odd: > > # > # Generated include files > # > include/config > include/generated > arch/*/include/generated > > first, given that those entries are clearly directories, it would > have seemed clearer to have added slash suffixes. again, the lack of > the slash won't hurt, but since other parts of this .gitignore file > seem to use slashes for clarity, one would think the same should apply > here. Have you checked the commit log to see the variety of committers? This sounds like the sort of thing that would not hurt to clean up, assuming sufficient testing is done to ensure there are no surprises. I'm sure a cleanup patch would be picked apart and well-vetted. > and another thing ... why both of these lines? > > include/generated > arch/*/include/generated > > isn't there a wildcard pattern that would subsume both of those > entries? I would assume so. Again, I'd look at the commit log. > finally, would it not make more sense to replace things like: > > Module.symvers > > with > > /Module.symvers > > since i'm fairly sure you only get one of those, yes? > > i thought there was one more thing i wanted to ask, but i can't > remember what it was. > > rday slainte mhath, RGB -- Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca> <www.TriColour.ca> -- \___ o \@ @ Ride yer bike! Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\% Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________