Comment 2 for bug 1005644

Hi Jeff,

Good idea ;-)

I have tested this patch in my local git repo <https://github.com/bert/pcb/tree/LP1005644>.

Copying .gitignore to .pcbignore in the toplevel pcb dir and the newlib
dir doesn't seem to give the expected results.

For example, when choosing "File"->"Open" still shows the Makefile and
Makefile.in etc. in both above mentioned dirs.

Also for choosing "File"->"Load element to buffer".

I have verified in config.h that:

<quote>
/* Define to 1 if you have the `fnmatch' function. */
#define HAVE_FNMATCH 1
</quote>

is set so that no "hard-coded internal fakery" is performed.

Maybe I have misunderstood the documentation or maybe the patch is not complete.

And maybe add a more extensive explanation of these rules in the
documentation.

For example, ".gitignore" files have the same functionality for git
and are parsed according following pattern formats, and the rules
are described in "man gitignore" as:

- A blank line matches no files, so it can serve as a separator for
  readability.

- A line starting with # serves as a comment.

- An optional prefix ! which negates the pattern; any matching file
  excluded by a previous pattern will become included again.
  If a negated pattern matches, this will override lower precedence
  patterns sources.

- 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).

- If the pattern does not contain a slash /, git treats it as a shell
  glob pattern and checks for a match against the pathname relative to
  the location of the .gitignore file (relative to the toplevel of the
  work tree if not from a .gitignore file).

- 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" or
  "tools/perf/Documentation/perf.html".

- A leading slash matches the beginning of the pathname.
  For example, "/*.c" matches "cat-file.c" but not
  "mozilla-sha1/sha1.c".

Kind regards,

Bert Timmerman.