Re: How do I qualify paths in the .gitignore file w.r.t. the repo root directory?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux