Thanks James and Junio. I'll try the leading slash. I assumed that the beginning slash means what it means for other tools (meaning a fully-qualified path to some file somewhere on the file system), but apparently such is not the case with git (and I conclude from this that it is actually not possible to store fully qualified paths _unless_ the $GIT_DIR is right under the root filesystem). This isn't a problem for me, and probably not for most folks, but it was confusing to me the way it was written in the man page. Brent On Mon, Feb 23, 2009 at 11:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Brent Goodrick <bgoodr@xxxxxxxxx> writes: > > > Say I have these files and directories [2]: > > > > /home/smart_tator/misc_files/.gitignore > > /home/smart_tator/misc_files/foo/ > > /home/smart_tator/misc_files/bar/ > > /home/smart_tator/misc_files/bar/baz/foo/ > > /home/smart_tator/misc_files/bar/baz/real/ > > > > then I do: > > > > cd /home/smart_tator/misc_files/; git init > > > > and say I have this line in that .gitignore file: > > > > foo/ > > > > And then I naively execute: > > > > git add bar/ > > > > then the bar/baz/real/ is added, but these are dutifully ignored: > > > > /home/smart_tator/misc_files/foo/ > > /home/smart_tator/misc_files/bar/baz/foo/ > > I think you are looking for "/foo/". From Documentation/gitignore.txt: > > - If the pattern ends with a slash, it is removed for the > purpose of the following description, but it would only find > a match with a directory. In other words, `foo/` will match a > directory `foo` and paths underneath it, but will not match a > regular file or a symbolic link `foo` (this is consistent > with the way how pathspec works in general in git). > > With this rule, (1) the trailing slash in your "foo/" tells git to match > only with directories, but (2) it behaves as if you said "foo" for all the > other rules. > > With "/foo/", you tell git to match only with a directory, and it is as if > you said "/foo". > > - If the pattern does not contain a slash '/', git treats it as > a shell glob pattern and checks for a match against the > pathname without leading directories. > > Your "foo/" now behaves the same way as "foo" behaves. You are telling > git to match directory foo anywhere in the tree. "/foo/" (now behaving > the same way as "/foo") does not satisfy this criteria so we would skip > this rule. > > - Otherwise, git treats the pattern as a shell glob suitable > for consumption by fnmatch(3) with the FNM_PATHNAME flag: > wildcards in the pattern will not match a / in the pathname. > For example, "Documentation/\*.html" matches > "Documentation/git.html" but not > "Documentation/ppc/ppc.html". A leading slash matches the > beginning of the pathname; for example, "/*.c" matches > "cat-file.c" but not "mozilla-sha1/sha1.c". > > Your "foo/" does not survive to this rule, but "/foo/" does. It now > behaves as "/foo" and its leading slash makes it match the beginning. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
