git-ls-files was broken by the setup_git_directory() calling changes,
because I had missed the fact that the "prefix" variable in that file was
static to the whole file, and unlike git-ls-tree (where I had fixed it
up), it ended up using two different variables with the same name
depending on what the scoping happened to be.

This fixes it up properly (by just removing the static variable, and
passing the automatic one around properly), and git-ls-files should work
again.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This changes the calling convention of built-in commands and
passes the "prefix" (i.e. pathname of $PWD relative to the
project root level) down to them.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This moves the code to add the per-directory ignore files for the base
directory into the library routine.

That not only allows us to turn the function push_exclude_per_directory()
static again, it also simplifies the library interface a lot (the caller
no longer needs to worry about any of the per-directory exclude files at
all).
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This moves the core directory traversal and filename exclusion logic
into the general git library, making it available for other users
directly.

If we ever want to do "git commit" or "git add" as a built-in (and we
do), we want to be able to handle most of git-ls-files as a library.

NOTE! Not all of git-ls-files is libified by this.  The index matching
and pathspec prefix calculation is still in ls-files.c, but this is a
big part of it.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Without the --directory flag, git-ls-files wouldn't ever list directories,
producing no output for empty directories, which is good since they cannot
be added and they bear no content, even untracked one (if Git ever starts
tracking directories on their own, this should obviously change since the
content notion will change).

With the --directory flag however, git-ls-files would list even empty
directories. This may be good in some situations but sometimes you want to
prevent that. This patch adds a --no-empty-directory option which makes
git-ls-files omit empty directories.
Signed-off-by: NPetr Baudis <pasky@suse.cz>

Without this patch, the last line of an exclude file is silently
ignored if it doesn't end with a newline.
Signed-off-by: NAlexandre Julliard <julliard@winehq.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Make git-ls-files --others --ignored recurse into non-excluded
subdirectories.

Typically when asking git-ls-files to display all files which are
ignored by one or more exclude patterns one would want it to recurse
into subdirectories which are not themselves excluded to see if
there are any excluded files contained within those subdirectories.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Earlier patch mistakenly used prefix_len when it meant
prefix_offset.  The latter is to strip the leading directories
when run from a subdirectory.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When you say "git commit Documentaiton" to make partial commit
for the files only in that directory, we did not detect that as
a misspelled pathname and attempted to commit index without
change.  If nothing matched, there is no harm done, but if the
index gets modified otherwise by having another valid pathspec
or after an explicit update-index, a user will not notice
without paying attention to the "git status" preview.

This introduces --error-unmatch option to ls-files, and uses it
to detect this common user error.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

To preserve compatibility with scripts that expect uppercase
letters to be shown, do not make '-t' to unconditionally show
the valid bit.  Introduce '-v' option for that.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When git-ls-files -o --exclude-per-directory=.gitignore is run
from a subdirectory, it did not read from .gitignore from its
parent directory.  Reading from them makes output from these two
commands consistent:

    $ git ls-files -o --exclude-per-directory=.gitignore Documentation
    $ cd Documentation &&
      git ls-files -o --exclude-per-directory=.gitignore
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is not really part of the proposed updates for CE_VALID,
but with this change, ls-files -t shows CE_VALID paths with
lowercase tag letters instead of the usual uppercase.  Useful
for checking out what is going on.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds a trailing slash to directory names in the output
when "--others --directory" option shows only untracked
directories and not their contents, to make them stand out.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When both howto-index.sh and howto/make-dist.txt exist under
Documentation/ directory, dir_exists() mistakenly checked it
without the trailing slash to see if there was something under
Documentation/howto directory, and did not realize there was,
because '-' sorts earlier than '/' and cache_name_pos() finds
howto-index.sh, which is not under howto/ directory.  This
caused --others --directory to show it which was incorrect.

Check the directory name with the trailing slash, because having
an entry that has such as a prefix is what we are looking for.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Darrin Thompson notes that git-ls-files -o reports all the unknown
files it finds in a work area.  Subversion and probably other systems
"simply ignore all the files and directories inside an unknown
directory and just note the directory as unknown."

With --directory option, ls-files --others shows untracked directories
without descending into them.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

ISO C99 (and GCC 3.x or later) lets you write a flexible array
at the end of a structure, like this:

	struct frotz {
		int xyzzy;
		char nitfol[]; /* more */
	};

GCC 2.95 and 2.96 let you to do this with "char nitfol[0]";
unfortunately this is not allowed by ISO C90.

This declares such construct like this:

	struct frotz {
		int xyzzy;
		char nitfol[FLEX_ARRAY]; /* more */
	};

and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
empty for others.

If you are using a C90 C compiler, you should be able
to override this with CFLAGS=-DFLEX_ARRAY=1 from the
command line of "make".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Somehow this option was not mentioned anywhere in the
documentation nor the usage string.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is to prepare for ls-tree updates.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

ls-files.c and read-tree.c miss the default configuration, in
particular the filemode=false part.  The recent +x bit flip made me
notice that, because git-merge refused to merge anything saying that
git-pull.sh is not up to date.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Jon Loeliger noticed that an unmerged path appears as
"Untracked" in git-status output, even though we show the same
path as updated/changed.  Since --others means "we have not told
git about that path", we should not show unmerged paths --
obviously, git knows about them; it just does not know what we
want to do about them yet.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For everyone cursed by dos/windows line endings (aka CRLF):

The code reading the .gitignore files (excludes and excludes per
directory) leaves \r in the patterns, which causes fnmatch to fail for
no obvious reason. Just remove a "\r" preceding a "\n"
unconditionally.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Useful if you have a file whose name starts with a dash.
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is a long overdue clean-up to the code for parsing and passing
diff options.  It also tightens some constness issues.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Add -m/--modified to show files that have been modified wrt. the index.

[jc: The original came from Brian Gerst on Sep 1st but it only checked
if the paths were cache dirty without actually checking the files were
modified.  I also added the usage string and a new test.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This reverts 6c5f9baa commit, whose
change breaks gcc-2.95.

Not that I ignore portability to compilers that are properly C99, but
keeping compilation with GCC working is more important, at least for
now.  We would probably end up declaring with "name[1]" and teach the
allocator to subtract one if we really aimed for portability, but that
is left for later rounds.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The "verify_pathspec()" function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

C99 denotes variable-sized members with [], not [0].
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>

This generalizes the git "glob" string to be a lot more like the
git-diff-* pathspecs (but there are still differences: the diff family
doesn't do any globbing, and because the diff family always generates the
full native pathname, it doesn't have the issue with "..").

It does three things:

 - it allows multiple matching strings, ie you can do things like

	git-ls-files arch/i386/ include/asm-i386/ | xargs grep pattern

 - the "matching" criteria is a combination of "exact path component
   match" (the same as the git-diff-* family), and "fnmatch()". However,
   you should be careful with the confusion between the git-ls-files
   internal globbing and the standard shell globbing, ie

	git-ls-files fs/*.c

   does globbing in the shell, and does something totally different from

	git-ls-files 'fs/*.c'

   which does the globbing inside git-ls-files.

   The latter has _one_ pathspec with a wildcard, and will match any .c
   file anywhere under the fs/ directory, while the former has been
   expanded by the shell into having _lots_ of pathspec entries, all of
   which are just in the top-level fs/ subdirectory. They will happily
   be matched exactly, but we will thus miss all the subdirectories under
   fs/.

   As a result, the first one will (on the current kernel) match 55 files,
   while the second one will match 664 files!

 - it uses the generic path prefixing, so that ".." and friends at the
   beginning of the path spec work automatically

   NOTE! When generating relative pathname output (the default), a
   pathspec that causes the base to be outside the current working
   directory will be rejected with an error message like:

	fatal: git-ls-files: cannot generate relative filenames containing '..'

   because we do not actually generate ".." in the output. However, the
   ".." format works fine for the --full-name case:

	cd arch/i386/kernel
	git-ls-files --full-name ../mm/

   results in

	arch/i386/mm/Makefile
	arch/i386/mm/boot_ioremap.c
	arch/i386/mm/discontig.c
	arch/i386/mm/extable.c
	arch/i386/mm/fault.c
	arch/i386/mm/highmem.c
	arch/i386/mm/hugetlbpage.c
	arch/i386/mm/init.c
	arch/i386/mm/ioremap.c
	arch/i386/mm/mmap.c
	arch/i386/mm/pageattr.c
	arch/i386/mm/pgtable.c

   Perhaps more commonly, the generic path prefixing means that "." and
   "./" automatically get simplified and work properly.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do

	cd arch/i386
	git-ls-files

and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).

The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).

The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.

For example, when doing

	git-ls-files 'arch/i386/p*/*.c'

the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.

This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.

For example:

	git-ls-files 'arch/i386/*.[ch]'

will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).

Also, while

	git-ls-files arch/i386/

will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.

These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do

	git-ls-files fs/*.c | xargs grep some_pattern

and it does what you want.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

All usage strings are now declared as static const char [].

This is carried over from my old git-pb branch.
Signed-off-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Pasky and others raised many valid points on the problems
initial exclude pattern enhancement work had.  Based on the
list discussion, rework the exclude logic to use "last match
determines its fate" rule, and order the list by exclude-from
(the fallback default pattern file), exclude-per-directory
(shallower to deeper, so deeper ones can override), and then
command line exclude patterns.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Add --exclude-per-directory=<name> option that specifies a file
to contain exclude patterns local to that directory and its
subdirectories.  Update the exclusion logic to be able to say
"include files that match this more specific pattern, even
though later exclude patterns may match them".  Also enhances
that a pattern can contain '/' in which case fnmatch is called
with FNM_PATHNAME flag to match the entire path. 
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Use SP as the column separator except the ones before path which
uses TAB, to make the output format consistent across ls-* and
diff-* commands.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This attempts to match "the directory '.git' anywhere in the
tree is ignored" approach taken in update-cache.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix various things that sparse complains about:
 - use NULL instead of 0
 - make sure we declare everything properly, or mark it static
 - use proper function declarations ("fn(void)" instead of "fn()")

Sparse is always right.