patch, 4 parts"make tags" improvements

A discussion earlier today made me notice that our "make tags" target includes some cruft that we shouldn't be indexing. This fixes that, and starts indexing some of the shell scripts, which is something I've been doing in a hacky way for a while. It's very convenient when working on the test suite (especially because I can never remember which functions are declared in test-lib.sh, and which in test-lib-functions.sh).

  [1/4]: Makefile: reformat FIND_SOURCE_FILES
  [2/4]: Makefile: exclude test cruft from FIND_SOURCE_FILES
  [3/4]: Makefile: match shell scripts in FIND_SOURCE_FILES
  [4/4]: Makefile: exclude contrib from FIND_SOURCE_FILES

 Makefile | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

-Peff

As we add to this in future commits, the formatting is going to make it harder and harder to read. Let's write it more as we would in a shell script, putting each logical block on its own line.

Signed-off-by: Jeff King <peff@peff.net>
---
Just to make the other patches easier to read; no behavior change
intended.

I was tempted to actually pull this out into its own find-source-files.sh script. I don't know if that is preferable or not; it certainly makes the "make tags" output less ugly.

 Makefile | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

The test directory may contain three types of files that match our patterns:

  1. Helper programs in t/helper.

  2. Sample data files (e.g., t/t4051/hello.c).

  3. Untracked cruft in trash directories and t/perf/build.

We want to match (1), but not the other two, as they just clutter up the list.

For the ls-files method, we can drop (2) with a negative pathspec. We do not have to care about (3), since ls-files will not list untracked files.

For `find`, we can match both cases with `-prune` patterns.

Signed-off-by: Jeff King <peff@peff.net>
---
I expected that:

  ':![tp][0-9][0-9][0-9][0-9]'

would work, but it doesn't. I think because we don't match intermediate directories against pathspecs. So you have to use wildcards to match the rest of the path.

 Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

We feed FIND_SOURCE_FILES to ctags to help developers navigate to particular functions, but we only feed C source code. The same feature can be helpful when working with shell scripts (especially the test suite). Modern versions of ctags know how to parse shell scripts; we just need to feed the filenames to it.

This patch specifically avoids including the individual test scripts themselves. Those are unlikely to be of interest, and there are a lot of them to process. It does pick up test-lib.sh and test-lib-functions.sh.

Note that our negative pathspec already excludes the individual scripts for the ls-files case, but we need to loosen the `find` rule to match it.

Signed-off-by: Jeff King <peff@peff.net>
---
Maybe people would find this annoying. It does increase the number of
entries in the tags file. I've been running something like it for a few
months and have found it useful.

It's also possible that some people have a version of ctags or etags that doesn't handle shell scripts. I imagine few enough people actually run "make tags" in the first place that we can probably try it and see.

 Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

When you're working on the git project, you're unlikely to care about random bits in contrib/ (e.g., you would not want to jump to the copy of xmalloc in the wincred credential helper). Nobody has really complained because there are relatively few C files in contrib.

Now that we're matching shell scripts, too, we get quite a few more hits, especially in the obsolete contrib/examples directory. Looking for usage() should turn up the one in git-sh-setup, not in some long-dead version of git-clone.

Let's just exclude all of contrib. Any specific projects there which are big enough to want tags can generate them separately.

Signed-off-by: Jeff King <peff@peff.net>
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)