2005-04-12 03:55:38 +02:00
|
|
|
/*
|
|
|
|
|
* This merges the file listing in the directory cache index
|
|
|
|
|
* with the actual working directory list, and shows different
|
|
|
|
|
* combinations of the two.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
|
*/
|
|
|
|
|
#include "cache.h"
|
2005-10-15 06:56:46 +02:00
|
|
|
#include "quote.h"
|
2006-05-17 04:02:14 +02:00
|
|
|
#include "dir.h"
|
2006-05-23 14:15:29 +02:00
|
|
|
#include "builtin.h"
|
2007-09-13 01:04:22 +02:00
|
|
|
#include "tree.h"
|
2009-02-17 15:27:11 +01:00
|
|
|
#include "parse-options.h"
|
2009-12-25 19:08:04 +01:00
|
|
|
#include "resolve-undo.h"
|
|
|
|
|
#include "string-list.h"
|
2005-04-12 03:55:38 +02:00
|
|
|
|
2006-08-15 19:23:48 +02:00
|
|
|
static int abbrev;
|
|
|
|
|
static int show_deleted;
|
|
|
|
|
static int show_cached;
|
|
|
|
|
static int show_others;
|
|
|
|
|
static int show_stage;
|
|
|
|
|
static int show_unmerged;
|
2009-12-25 19:08:04 +01:00
|
|
|
static int show_resolve_undo;
|
2006-08-15 19:23:48 +02:00
|
|
|
static int show_modified;
|
|
|
|
|
static int show_killed;
|
|
|
|
|
static int show_valid_bit;
|
2005-04-15 20:11:01 +02:00
|
|
|
static int line_terminator = '\n';
|
2010-07-31 00:35:59 +02:00
|
|
|
static int debug_mode;
|
2005-04-12 03:55:38 +02:00
|
|
|
|
2010-06-03 15:39:18 +02:00
|
|
|
static const char *prefix;
|
|
|
|
|
static int max_prefix_len;
|
2006-08-15 19:23:48 +02:00
|
|
|
static int prefix_len;
|
|
|
|
|
static const char **pathspec;
|
|
|
|
|
static int error_unmatch;
|
|
|
|
|
static char *ps_matched;
|
2007-09-13 01:04:22 +02:00
|
|
|
static const char *with_tree;
|
2009-02-17 15:27:11 +01:00
|
|
|
static int exc_given;
|
2013-01-06 17:58:04 +01:00
|
|
|
static int exclude_args;
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
2005-04-22 04:47:08 +02:00
|
|
|
static const char *tag_cached = "";
|
|
|
|
|
static const char *tag_unmerged = "";
|
|
|
|
|
static const char *tag_removed = "";
|
|
|
|
|
static const char *tag_other = "";
|
2005-05-13 02:17:54 +02:00
|
|
|
static const char *tag_killed = "";
|
2005-09-20 00:11:15 +02:00
|
|
|
static const char *tag_modified = "";
|
2009-08-20 15:46:57 +02:00
|
|
|
static const char *tag_skip_worktree = "";
|
2009-12-25 19:08:04 +01:00
|
|
|
static const char *tag_resolve_undo = "";
|
2005-04-22 04:47:08 +02:00
|
|
|
|
2013-06-25 17:53:46 +02:00
|
|
|
static void write_name(const char *name)
|
2010-06-03 15:39:18 +02:00
|
|
|
{
|
quote.c: substitute path_relative with relative_path
Substitute the function path_relative in quote.c with the function
relative_path. Function relative_path can be treated as an enhanced
and more robust version of path_relative.
Outputs of path_relative and it's replacement (relative_path) are the
same for the following cases:
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/c/ /a/b/ c/ c/
/a/b/c /a/b/ c c
/a/ /a/b/ ../ ../
/ /a/b/ ../../ ../../
/a/c /a/b/ ../c ../c
/x/y /a/b/ ../../x/y ../../x/y
a/b/c/ a/b/ c/ c/
a/ a/b/ ../ ../
x/y a/b/ ../../x/y ../../x/y
/a/b (empty) /a/b /a/b
/a/b (null) /a/b /a/b
a/b (empty) a/b a/b
a/b (null) a/b a/b
But if both of the path and the prefix are the same, or the returned
relative path should be the current directory, the outputs of both
functions are different. Function relative_path returns "./", while
function path_relative returns empty string.
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/ /a/b/ (empty) ./
a/b/ a/b/ (empty) ./
(empty) (null) (empty) ./
(empty) (empty) (empty) ./
But the callers of path_relative can handle such cases, or never
encounter this issue at all, because:
* In function quote_path_relative, if the output of path_relative is
empty, append "./" to it, like:
if (!out->len)
strbuf_addstr(out, "./");
* Another caller is write_name_quoted_relative, which is only used
by builtin/ls-files.c. git-ls-files only show files, so path of
files will never be identical with the prefix of a directory.
The following differences show that path_relative does not handle
extra slashes properly:
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a//b//c/ //a/b// ../../../../a//b//c/ c/
a/b//c a//b ../b//c c
And if prefix has no trailing slash, path_relative does not work
properly either. But since prefix always has a trailing slash, it's
not a problem.
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/c/ /a/b b/c/ c/
/a/b /a/b b ./
/a/b/ /a/b b/ ./
/a /a/b/ ../../a ../
a/b/c/ a/b b/c/ c/
a/b/ a/b b/ ./
a a/b ../a ../
x/y a/b/ ../x/y ../../x/y
a/c a/b c ../c
/a/ /a/b (empty) ../
(empty) /a/b ../../ ./
One tricky part in this conversion is write_name() function in
ls-files.c. It takes a counted string, <name, len>, that is to be
made relative to <prefix, prefix_len> and then quoted. Because
write_name_quoted_relative() still takes these two parameters as
counted string, but ignores the count and treat these two as
NUL-terminated strings, this conversion needs to be audited for its
callers:
- For <name, len>, all three callers of write_name() passes a
NUL-terminated string and its true length, so this patch makes
"len" unused.
- For <prefix, prefix_len>, prefix could be a string that is longer
than empty while prefix_len could be 0 when "--full-name" option
is used. This is fixed by checking prefix_len in write_name()
and calling write_name_quoted_relative() with NULL when
prefix_len is set to 0. Again, this makes "prefix_len" given to
write_name_quoted_relative() unused, without introducing a bug.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-25 17:53:44 +02:00
|
|
|
/*
|
2013-06-25 17:53:46 +02:00
|
|
|
* With "--full-name", prefix_len=0; this caller needs to pass
|
|
|
|
|
* an empty string in that case (a NULL is good for "").
|
quote.c: substitute path_relative with relative_path
Substitute the function path_relative in quote.c with the function
relative_path. Function relative_path can be treated as an enhanced
and more robust version of path_relative.
Outputs of path_relative and it's replacement (relative_path) are the
same for the following cases:
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/c/ /a/b/ c/ c/
/a/b/c /a/b/ c c
/a/ /a/b/ ../ ../
/ /a/b/ ../../ ../../
/a/c /a/b/ ../c ../c
/x/y /a/b/ ../../x/y ../../x/y
a/b/c/ a/b/ c/ c/
a/ a/b/ ../ ../
x/y a/b/ ../../x/y ../../x/y
/a/b (empty) /a/b /a/b
/a/b (null) /a/b /a/b
a/b (empty) a/b a/b
a/b (null) a/b a/b
But if both of the path and the prefix are the same, or the returned
relative path should be the current directory, the outputs of both
functions are different. Function relative_path returns "./", while
function path_relative returns empty string.
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/ /a/b/ (empty) ./
a/b/ a/b/ (empty) ./
(empty) (null) (empty) ./
(empty) (empty) (empty) ./
But the callers of path_relative can handle such cases, or never
encounter this issue at all, because:
* In function quote_path_relative, if the output of path_relative is
empty, append "./" to it, like:
if (!out->len)
strbuf_addstr(out, "./");
* Another caller is write_name_quoted_relative, which is only used
by builtin/ls-files.c. git-ls-files only show files, so path of
files will never be identical with the prefix of a directory.
The following differences show that path_relative does not handle
extra slashes properly:
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a//b//c/ //a/b// ../../../../a//b//c/ c/
a/b//c a//b ../b//c c
And if prefix has no trailing slash, path_relative does not work
properly either. But since prefix always has a trailing slash, it's
not a problem.
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/c/ /a/b b/c/ c/
/a/b /a/b b ./
/a/b/ /a/b b/ ./
/a /a/b/ ../../a ../
a/b/c/ a/b b/c/ c/
a/b/ a/b b/ ./
a a/b ../a ../
x/y a/b/ ../x/y ../../x/y
a/c a/b c ../c
/a/ /a/b (empty) ../
(empty) /a/b ../../ ./
One tricky part in this conversion is write_name() function in
ls-files.c. It takes a counted string, <name, len>, that is to be
made relative to <prefix, prefix_len> and then quoted. Because
write_name_quoted_relative() still takes these two parameters as
counted string, but ignores the count and treat these two as
NUL-terminated strings, this conversion needs to be audited for its
callers:
- For <name, len>, all three callers of write_name() passes a
NUL-terminated string and its true length, so this patch makes
"len" unused.
- For <prefix, prefix_len>, prefix could be a string that is longer
than empty while prefix_len could be 0 when "--full-name" option
is used. This is fixed by checking prefix_len in write_name()
and calling write_name_quoted_relative() with NULL when
prefix_len is set to 0. Again, this makes "prefix_len" given to
write_name_quoted_relative() unused, without introducing a bug.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-25 17:53:44 +02:00
|
|
|
*/
|
2013-06-25 17:53:46 +02:00
|
|
|
write_name_quoted_relative(name, prefix_len ? prefix : NULL,
|
|
|
|
|
stdout, line_terminator);
|
2010-06-03 15:39:18 +02:00
|
|
|
}
|
|
|
|
|
|
2006-05-17 04:02:14 +02:00
|
|
|
static void show_dir_entry(const char *tag, struct dir_entry *ent)
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
{
|
2010-06-03 15:39:18 +02:00
|
|
|
int len = max_prefix_len;
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
|
|
|
|
if (len >= ent->len)
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git ls-files: internal error - directory entry not superset of prefix");
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
2009-01-14 15:54:35 +01:00
|
|
|
if (!match_pathspec(pathspec, ent->name, ent->len, len, ps_matched))
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
return;
|
|
|
|
|
|
2005-10-15 06:56:46 +02:00
|
|
|
fputs(tag, stdout);
|
2013-06-25 17:53:46 +02:00
|
|
|
write_name(ent->name);
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
}
|
|
|
|
|
|
2006-05-17 04:02:14 +02:00
|
|
|
static void show_other_files(struct dir_struct *dir)
|
2005-11-07 02:26:31 +01:00
|
|
|
{
|
|
|
|
|
int i;
|
2007-04-15 01:22:08 +02:00
|
|
|
|
2006-05-17 04:02:14 +02:00
|
|
|
for (i = 0; i < dir->nr; i++) {
|
|
|
|
|
struct dir_entry *ent = dir->entries[i];
|
2008-10-16 17:07:26 +02:00
|
|
|
if (!cache_name_is_other(ent->name, ent->len))
|
|
|
|
|
continue;
|
2005-11-07 02:26:31 +01:00
|
|
|
show_dir_entry(tag_other, ent);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-05-17 04:02:14 +02:00
|
|
|
static void show_killed_files(struct dir_struct *dir)
|
2005-05-13 02:17:54 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
2006-05-17 04:02:14 +02:00
|
|
|
for (i = 0; i < dir->nr; i++) {
|
|
|
|
|
struct dir_entry *ent = dir->entries[i];
|
2005-05-13 02:17:54 +02:00
|
|
|
char *cp, *sp;
|
|
|
|
|
int pos, len, killed = 0;
|
|
|
|
|
|
|
|
|
|
for (cp = ent->name; cp - ent->name < ent->len; cp = sp + 1) {
|
|
|
|
|
sp = strchr(cp, '/');
|
|
|
|
|
if (!sp) {
|
|
|
|
|
/* If ent->name is prefix of an entry in the
|
|
|
|
|
* cache, it will be killed.
|
|
|
|
|
*/
|
|
|
|
|
pos = cache_name_pos(ent->name, ent->len);
|
|
|
|
|
if (0 <= pos)
|
|
|
|
|
die("bug in show-killed-files");
|
|
|
|
|
pos = -pos - 1;
|
|
|
|
|
while (pos < active_nr &&
|
|
|
|
|
ce_stage(active_cache[pos]))
|
|
|
|
|
pos++; /* skip unmerged */
|
|
|
|
|
if (active_nr <= pos)
|
|
|
|
|
break;
|
|
|
|
|
/* pos points at a name immediately after
|
|
|
|
|
* ent->name in the cache. Does it expect
|
|
|
|
|
* ent->name to be a directory?
|
|
|
|
|
*/
|
|
|
|
|
len = ce_namelen(active_cache[pos]);
|
|
|
|
|
if ((ent->len < len) &&
|
|
|
|
|
!strncmp(active_cache[pos]->name,
|
|
|
|
|
ent->name, ent->len) &&
|
|
|
|
|
active_cache[pos]->name[ent->len] == '/')
|
|
|
|
|
killed = 1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
if (0 <= cache_name_pos(ent->name, sp - ent->name)) {
|
|
|
|
|
/* If any of the leading directories in
|
|
|
|
|
* ent->name is registered in the cache,
|
|
|
|
|
* ent->name will be killed.
|
|
|
|
|
*/
|
|
|
|
|
killed = 1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (killed)
|
2006-05-17 04:02:14 +02:00
|
|
|
show_dir_entry(tag_killed, dir->entries[i]);
|
2005-05-13 02:17:54 +02:00
|
|
|
}
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
|
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 17:29:00 +02:00
|
|
|
static void show_ce_entry(const char *tag, const struct cache_entry *ce)
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
{
|
2010-06-03 15:39:18 +02:00
|
|
|
int len = max_prefix_len;
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
|
|
|
|
if (len >= ce_namelen(ce))
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git ls-files: internal error - cache entry not superset of prefix");
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
2009-01-14 15:54:35 +01:00
|
|
|
if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), len, ps_matched))
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
return;
|
|
|
|
|
|
2006-02-12 10:47:57 +01:00
|
|
|
if (tag && *tag && show_valid_bit &&
|
2008-01-15 01:03:17 +01:00
|
|
|
(ce->ce_flags & CE_VALID)) {
|
2006-02-09 06:50:18 +01:00
|
|
|
static char alttag[4];
|
|
|
|
|
memcpy(alttag, tag, 3);
|
|
|
|
|
if (isalpha(tag[0]))
|
|
|
|
|
alttag[0] = tolower(tag[0]);
|
|
|
|
|
else if (tag[0] == '?')
|
|
|
|
|
alttag[0] = '!';
|
|
|
|
|
else {
|
|
|
|
|
alttag[0] = 'v';
|
|
|
|
|
alttag[1] = tag[0];
|
|
|
|
|
alttag[2] = ' ';
|
|
|
|
|
alttag[3] = 0;
|
|
|
|
|
}
|
|
|
|
|
tag = alttag;
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-15 06:56:46 +02:00
|
|
|
if (!show_stage) {
|
|
|
|
|
fputs(tag, stdout);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 00:42:15 +02:00
|
|
|
} else {
|
2005-10-15 06:56:46 +02:00
|
|
|
printf("%s%06o %s %d\t",
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
tag,
|
2008-01-15 01:03:17 +01:00
|
|
|
ce->ce_mode,
|
2010-03-20 19:55:28 +01:00
|
|
|
find_unique_abbrev(ce->sha1,abbrev),
|
2005-10-15 06:56:46 +02:00
|
|
|
ce_stage(ce));
|
|
|
|
|
}
|
2013-06-25 17:53:46 +02:00
|
|
|
write_name(ce->name);
|
2010-07-31 00:35:59 +02:00
|
|
|
if (debug_mode) {
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 17:29:00 +02:00
|
|
|
const struct stat_data *sd = &ce->ce_stat_data;
|
2013-06-20 10:37:50 +02:00
|
|
|
|
|
|
|
|
printf(" ctime: %d:%d\n", sd->sd_ctime.sec, sd->sd_ctime.nsec);
|
|
|
|
|
printf(" mtime: %d:%d\n", sd->sd_mtime.sec, sd->sd_mtime.nsec);
|
|
|
|
|
printf(" dev: %d\tino: %d\n", sd->sd_dev, sd->sd_ino);
|
|
|
|
|
printf(" uid: %d\tgid: %d\n", sd->sd_uid, sd->sd_gid);
|
|
|
|
|
printf(" size: %d\tflags: %x\n", sd->sd_size, ce->ce_flags);
|
2010-07-31 00:35:59 +02:00
|
|
|
}
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
}
|
|
|
|
|
|
2010-06-03 15:39:18 +02:00
|
|
|
static void show_ru_info(void)
|
2009-12-25 19:08:04 +01:00
|
|
|
{
|
2010-07-03 14:41:54 +02:00
|
|
|
struct string_list_item *item;
|
|
|
|
|
|
2009-12-25 19:08:04 +01:00
|
|
|
if (!the_index.resolve_undo)
|
|
|
|
|
return;
|
2010-07-03 14:41:54 +02:00
|
|
|
|
|
|
|
|
for_each_string_list_item(item, the_index.resolve_undo) {
|
|
|
|
|
const char *path = item->string;
|
|
|
|
|
struct resolve_undo_info *ui = item->util;
|
|
|
|
|
int i, len;
|
|
|
|
|
|
|
|
|
|
len = strlen(path);
|
|
|
|
|
if (len < max_prefix_len)
|
|
|
|
|
continue; /* outside of the prefix */
|
|
|
|
|
if (!match_pathspec(pathspec, path, len, max_prefix_len, ps_matched))
|
|
|
|
|
continue; /* uninterested */
|
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
|
if (!ui->mode[i])
|
|
|
|
|
continue;
|
|
|
|
|
printf("%s%06o %s %d\t", tag_resolve_undo, ui->mode[i],
|
|
|
|
|
find_unique_abbrev(ui->sha1[i], abbrev),
|
|
|
|
|
i + 1);
|
2013-06-25 17:53:46 +02:00
|
|
|
write_name(path);
|
2010-07-03 14:41:54 +02:00
|
|
|
}
|
|
|
|
|
}
|
2009-12-25 19:08:04 +01:00
|
|
|
}
|
|
|
|
|
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 17:29:00 +02:00
|
|
|
static int ce_excluded(struct dir_struct *dir, const struct cache_entry *ce)
|
2012-06-06 06:17:52 +02:00
|
|
|
{
|
|
|
|
|
int dtype = ce_to_dtype(ce);
|
2013-04-15 21:12:57 +02:00
|
|
|
return is_excluded(dir, ce->name, &dtype);
|
2012-06-06 06:17:52 +02:00
|
|
|
}
|
|
|
|
|
|
2010-06-03 15:39:18 +02:00
|
|
|
static void show_files(struct dir_struct *dir)
|
2005-04-12 03:55:38 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* For cached/deleted files we don't need to even do the readdir */
|
2005-05-13 02:17:54 +02:00
|
|
|
if (show_others || show_killed) {
|
2009-05-14 22:22:36 +02:00
|
|
|
fill_directory(dir, pathspec);
|
2005-05-13 02:17:54 +02:00
|
|
|
if (show_others)
|
2006-05-17 04:02:14 +02:00
|
|
|
show_other_files(dir);
|
2005-05-13 02:17:54 +02:00
|
|
|
if (show_killed)
|
2006-05-17 04:02:14 +02:00
|
|
|
show_killed_files(dir);
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
2013-06-13 20:19:44 +02:00
|
|
|
if (show_cached || show_stage) {
|
2005-04-12 03:55:38 +02:00
|
|
|
for (i = 0; i < active_nr; i++) {
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 17:29:00 +02:00
|
|
|
const struct cache_entry *ce = active_cache[i];
|
2012-06-01 20:28:00 +02:00
|
|
|
if ((dir->flags & DIR_SHOW_IGNORED) &&
|
2013-04-15 21:12:57 +02:00
|
|
|
!ce_excluded(dir, ce))
|
ls-files: unbreak "ls-files -i"
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30 20:05:52 +01:00
|
|
|
continue;
|
2005-04-16 21:43:32 +02:00
|
|
|
if (show_unmerged && !ce_stage(ce))
|
|
|
|
|
continue;
|
2008-01-15 01:03:17 +01:00
|
|
|
if (ce->ce_flags & CE_UPDATE)
|
2007-09-13 01:04:22 +02:00
|
|
|
continue;
|
2009-08-20 15:46:57 +02:00
|
|
|
show_ce_entry(ce_stage(ce) ? tag_unmerged :
|
|
|
|
|
(ce_skip_worktree(ce) ? tag_skip_worktree : tag_cached), ce);
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
|
}
|
2013-06-13 20:19:44 +02:00
|
|
|
if (show_deleted || show_modified) {
|
2005-04-12 03:55:38 +02:00
|
|
|
for (i = 0; i < active_nr; i++) {
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 17:29:00 +02:00
|
|
|
const struct cache_entry *ce = active_cache[i];
|
2005-04-12 03:55:38 +02:00
|
|
|
struct stat st;
|
2005-09-20 00:11:15 +02:00
|
|
|
int err;
|
2012-06-01 20:28:00 +02:00
|
|
|
if ((dir->flags & DIR_SHOW_IGNORED) &&
|
2013-04-15 21:12:57 +02:00
|
|
|
!ce_excluded(dir, ce))
|
ls-files: unbreak "ls-files -i"
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30 20:05:52 +01:00
|
|
|
continue;
|
2008-11-16 09:10:25 +01:00
|
|
|
if (ce->ce_flags & CE_UPDATE)
|
|
|
|
|
continue;
|
2009-08-20 15:46:58 +02:00
|
|
|
if (ce_skip_worktree(ce))
|
|
|
|
|
continue;
|
2005-09-20 00:11:15 +02:00
|
|
|
err = lstat(ce->name, &st);
|
|
|
|
|
if (show_deleted && err)
|
|
|
|
|
show_ce_entry(tag_removed, ce);
|
2006-02-09 06:50:18 +01:00
|
|
|
if (show_modified && ce_modified(ce, &st, 0))
|
2005-09-20 00:11:15 +02:00
|
|
|
show_ce_entry(tag_modified, ce);
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Prune the index to only contain stuff starting with "prefix"
|
|
|
|
|
*/
|
2006-07-31 22:13:55 +02:00
|
|
|
static void prune_cache(const char *prefix)
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
{
|
2010-06-03 15:39:18 +02:00
|
|
|
int pos = cache_name_pos(prefix, max_prefix_len);
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
unsigned int first, last;
|
|
|
|
|
|
|
|
|
|
if (pos < 0)
|
|
|
|
|
pos = -pos-1;
|
2007-10-03 07:44:15 +02:00
|
|
|
memmove(active_cache, active_cache + pos,
|
|
|
|
|
(active_nr - pos) * sizeof(struct cache_entry *));
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
active_nr -= pos;
|
|
|
|
|
first = 0;
|
|
|
|
|
last = active_nr;
|
|
|
|
|
while (last > first) {
|
|
|
|
|
int next = (last + first) >> 1;
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 17:29:00 +02:00
|
|
|
const struct cache_entry *ce = active_cache[next];
|
2010-06-03 15:39:18 +02:00
|
|
|
if (!strncmp(ce->name, prefix, max_prefix_len)) {
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
first = next+1;
|
|
|
|
|
continue;
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
last = next;
|
|
|
|
|
}
|
|
|
|
|
active_nr = last;
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-07 14:43:03 +01:00
|
|
|
static void strip_trailing_slash_from_submodules(void)
|
|
|
|
|
{
|
|
|
|
|
const char **p;
|
|
|
|
|
|
|
|
|
|
for (p = pathspec; *p != NULL; p++) {
|
|
|
|
|
int len = strlen(*p), pos;
|
|
|
|
|
|
|
|
|
|
if (len < 1 || (*p)[len - 1] != '/')
|
|
|
|
|
continue;
|
|
|
|
|
pos = cache_name_pos(*p, len - 1);
|
|
|
|
|
if (pos >= 0 && S_ISGITLINK(active_cache[pos]->ce_mode))
|
|
|
|
|
*p = xstrndup(*p, len - 1);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-09-13 01:04:22 +02:00
|
|
|
/*
|
|
|
|
|
* Read the tree specified with --with-tree option
|
|
|
|
|
* (typically, HEAD) into stage #1 and then
|
|
|
|
|
* squash them down to stage #0. This is used for
|
|
|
|
|
* --error-unmatch to list and check the path patterns
|
|
|
|
|
* that were given from the command line. We are not
|
|
|
|
|
* going to write this index out.
|
|
|
|
|
*/
|
2007-11-18 10:13:32 +01:00
|
|
|
void overlay_tree_on_cache(const char *tree_name, const char *prefix)
|
2007-09-13 01:04:22 +02:00
|
|
|
{
|
|
|
|
|
struct tree *tree;
|
|
|
|
|
unsigned char sha1[20];
|
2011-03-25 10:34:19 +01:00
|
|
|
struct pathspec pathspec;
|
2007-09-13 01:04:22 +02:00
|
|
|
struct cache_entry *last_stage0 = NULL;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (get_sha1(tree_name, sha1))
|
|
|
|
|
die("tree-ish %s not found.", tree_name);
|
|
|
|
|
tree = parse_tree_indirect(sha1);
|
|
|
|
|
if (!tree)
|
|
|
|
|
die("bad tree-ish %s", tree_name);
|
|
|
|
|
|
|
|
|
|
/* Hoist the unmerged entries up to stage #3 to make room */
|
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
|
if (!ce_stage(ce))
|
|
|
|
|
continue;
|
2008-01-15 01:03:17 +01:00
|
|
|
ce->ce_flags |= CE_STAGEMASK;
|
2007-09-13 01:04:22 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (prefix) {
|
|
|
|
|
static const char *(matchbuf[2]);
|
|
|
|
|
matchbuf[0] = prefix;
|
2008-11-16 09:15:43 +01:00
|
|
|
matchbuf[1] = NULL;
|
2011-03-25 10:34:19 +01:00
|
|
|
init_pathspec(&pathspec, matchbuf);
|
2012-11-18 10:13:06 +01:00
|
|
|
pathspec.items[0].nowildcard_len = pathspec.items[0].len;
|
2007-09-13 01:04:22 +02:00
|
|
|
} else
|
2011-03-25 10:34:19 +01:00
|
|
|
init_pathspec(&pathspec, NULL);
|
|
|
|
|
if (read_tree(tree, 1, &pathspec))
|
2007-09-13 01:04:22 +02:00
|
|
|
die("unable to read tree entries %s", tree_name);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
|
switch (ce_stage(ce)) {
|
|
|
|
|
case 0:
|
|
|
|
|
last_stage0 = ce;
|
|
|
|
|
/* fallthru */
|
|
|
|
|
default:
|
|
|
|
|
continue;
|
|
|
|
|
case 1:
|
|
|
|
|
/*
|
|
|
|
|
* If there is stage #0 entry for this, we do not
|
|
|
|
|
* need to show it. We use CE_UPDATE bit to mark
|
|
|
|
|
* such an entry.
|
|
|
|
|
*/
|
|
|
|
|
if (last_stage0 &&
|
|
|
|
|
!strcmp(last_stage0->name, ce->name))
|
2008-01-15 01:03:17 +01:00
|
|
|
ce->ce_flags |= CE_UPDATE;
|
2007-09-13 01:04:22 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-01 23:19:58 +02:00
|
|
|
int report_path_error(const char *ps_matched, const char **pathspec, const char *prefix)
|
2007-11-18 10:13:32 +01:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Make sure all pathspec matched; otherwise it is an error.
|
|
|
|
|
*/
|
2011-08-01 23:19:58 +02:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
const char *name;
|
2007-11-18 10:13:32 +01:00
|
|
|
int num, errors = 0;
|
|
|
|
|
for (num = 0; pathspec[num]; num++) {
|
|
|
|
|
int other, found_dup;
|
|
|
|
|
|
|
|
|
|
if (ps_matched[num])
|
|
|
|
|
continue;
|
|
|
|
|
/*
|
|
|
|
|
* The caller might have fed identical pathspec
|
|
|
|
|
* twice. Do not barf on such a mistake.
|
|
|
|
|
*/
|
|
|
|
|
for (found_dup = other = 0;
|
|
|
|
|
!found_dup && pathspec[other];
|
|
|
|
|
other++) {
|
|
|
|
|
if (other == num || !ps_matched[other])
|
|
|
|
|
continue;
|
|
|
|
|
if (!strcmp(pathspec[other], pathspec[num]))
|
|
|
|
|
/*
|
|
|
|
|
* Ok, we have a match already.
|
|
|
|
|
*/
|
|
|
|
|
found_dup = 1;
|
|
|
|
|
}
|
|
|
|
|
if (found_dup)
|
|
|
|
|
continue;
|
|
|
|
|
|
2013-06-25 17:53:45 +02:00
|
|
|
name = quote_path_relative(pathspec[num], prefix, &sb);
|
2007-11-18 10:13:32 +01:00
|
|
|
error("pathspec '%s' did not match any file(s) known to git.",
|
2011-08-01 23:19:58 +02:00
|
|
|
name);
|
2007-11-18 10:13:32 +01:00
|
|
|
errors++;
|
|
|
|
|
}
|
2011-08-01 23:19:58 +02:00
|
|
|
strbuf_release(&sb);
|
2007-11-18 10:13:32 +01:00
|
|
|
return errors;
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-17 15:27:11 +01:00
|
|
|
static const char * const ls_files_usage[] = {
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("git ls-files [options] [<file>...]"),
|
2009-02-17 15:27:11 +01:00
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int option_parse_z(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
|
|
|
|
line_terminator = unset ? '\n' : '\0';
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int option_parse_exclude(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
2013-01-16 14:25:58 +01:00
|
|
|
struct string_list *exclude_list = opt->value;
|
2009-02-17 15:27:11 +01:00
|
|
|
|
|
|
|
|
exc_given = 1;
|
2013-01-16 14:25:58 +01:00
|
|
|
string_list_append(exclude_list, arg);
|
2009-02-17 15:27:11 +01:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int option_parse_exclude_from(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
|
|
|
|
struct dir_struct *dir = opt->value;
|
|
|
|
|
|
|
|
|
|
exc_given = 1;
|
|
|
|
|
add_excludes_from_file(dir, arg);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int option_parse_exclude_standard(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
|
|
|
|
struct dir_struct *dir = opt->value;
|
|
|
|
|
|
|
|
|
|
exc_given = 1;
|
|
|
|
|
setup_standard_excludes(dir);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2005-04-29 00:06:25 +02:00
|
|
|
|
2010-06-03 15:39:18 +02:00
|
|
|
int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
|
2005-04-12 03:55:38 +02:00
|
|
|
{
|
2013-01-16 14:25:58 +01:00
|
|
|
int require_work_tree = 0, show_tag = 0, i;
|
2010-06-03 15:39:18 +02:00
|
|
|
const char *max_prefix;
|
2006-05-17 04:02:14 +02:00
|
|
|
struct dir_struct dir;
|
2013-01-16 14:25:58 +01:00
|
|
|
struct exclude_list *el;
|
|
|
|
|
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
|
2009-02-17 15:27:11 +01:00
|
|
|
struct option builtin_ls_files_options[] = {
|
|
|
|
|
{ OPTION_CALLBACK, 'z', NULL, NULL, NULL,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("paths are separated with NUL character"),
|
2009-02-17 15:27:11 +01:00
|
|
|
PARSE_OPT_NOARG, option_parse_z },
|
|
|
|
|
OPT_BOOLEAN('t', NULL, &show_tag,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("identify the file status with tags")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BOOLEAN('v', NULL, &show_valid_bit,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("use lowercase letters for 'assume unchanged' files")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BOOLEAN('c', "cached", &show_cached,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show cached files in the output (default)")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BOOLEAN('d', "deleted", &show_deleted,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show deleted files in the output")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BOOLEAN('m', "modified", &show_modified,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show modified files in the output")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BOOLEAN('o', "others", &show_others,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show other files in the output")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BIT('i', "ignored", &dir.flags,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show ignored files in the output"),
|
2009-02-17 15:27:11 +01:00
|
|
|
DIR_SHOW_IGNORED),
|
|
|
|
|
OPT_BOOLEAN('s', "stage", &show_stage,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show staged contents' object name in the output")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BOOLEAN('k', "killed", &show_killed,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show files on the filesystem that need to be removed")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_BIT(0, "directory", &dir.flags,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show 'other' directories' name only"),
|
2009-02-17 15:27:11 +01:00
|
|
|
DIR_SHOW_OTHER_DIRECTORIES),
|
2009-05-08 07:01:17 +02:00
|
|
|
OPT_NEGBIT(0, "empty-directory", &dir.flags,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("don't show empty directories"),
|
2009-02-17 15:27:11 +01:00
|
|
|
DIR_HIDE_EMPTY_DIRECTORIES),
|
|
|
|
|
OPT_BOOLEAN('u', "unmerged", &show_unmerged,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show unmerged files in the output")),
|
2009-12-25 19:08:04 +01:00
|
|
|
OPT_BOOLEAN(0, "resolve-undo", &show_resolve_undo,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("show resolve-undo information")),
|
2013-01-24 06:19:10 +01:00
|
|
|
{ OPTION_CALLBACK, 'x', "exclude", &exclude_list, N_("pattern"),
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("skip files matching pattern"),
|
2009-02-17 15:27:11 +01:00
|
|
|
0, option_parse_exclude },
|
2012-08-20 14:32:20 +02:00
|
|
|
{ OPTION_CALLBACK, 'X', "exclude-from", &dir, N_("file"),
|
|
|
|
|
N_("exclude patterns are read from <file>"),
|
2009-02-17 15:27:11 +01:00
|
|
|
0, option_parse_exclude_from },
|
2012-08-20 14:32:20 +02:00
|
|
|
OPT_STRING(0, "exclude-per-directory", &dir.exclude_per_dir, N_("file"),
|
|
|
|
|
N_("read additional per-directory exclude patterns in <file>")),
|
2009-02-17 15:27:11 +01:00
|
|
|
{ OPTION_CALLBACK, 0, "exclude-standard", &dir, NULL,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("add the standard git exclusions"),
|
2009-02-17 15:27:11 +01:00
|
|
|
PARSE_OPT_NOARG, option_parse_exclude_standard },
|
2010-06-03 15:39:18 +02:00
|
|
|
{ OPTION_SET_INT, 0, "full-name", &prefix_len, NULL,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("make the output relative to the project top directory"),
|
2009-02-17 15:27:11 +01:00
|
|
|
PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL },
|
|
|
|
|
OPT_BOOLEAN(0, "error-unmatch", &error_unmatch,
|
2012-08-20 14:32:20 +02:00
|
|
|
N_("if any <file> is not in the index, treat this as an error")),
|
|
|
|
|
OPT_STRING(0, "with-tree", &with_tree, N_("tree-ish"),
|
|
|
|
|
N_("pretend that paths removed since <tree-ish> are still present")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT__ABBREV(&abbrev),
|
2012-08-20 14:32:20 +02:00
|
|
|
OPT_BOOLEAN(0, "debug", &debug_mode, N_("show debugging data")),
|
2009-02-17 15:27:11 +01:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
2005-04-12 03:55:38 +02:00
|
|
|
|
2010-10-22 08:48:14 +02:00
|
|
|
if (argc == 2 && !strcmp(argv[1], "-h"))
|
|
|
|
|
usage_with_options(ls_files_usage, builtin_ls_files_options);
|
|
|
|
|
|
2006-05-17 04:02:14 +02:00
|
|
|
memset(&dir, 0, sizeof(dir));
|
2010-06-03 15:39:18 +02:00
|
|
|
prefix = cmd_prefix;
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
if (prefix)
|
2010-06-03 15:39:18 +02:00
|
|
|
prefix_len = strlen(prefix);
|
2008-05-14 19:46:53 +02:00
|
|
|
git_config(git_default_config, NULL);
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
2009-08-20 15:47:01 +02:00
|
|
|
if (read_cache() < 0)
|
|
|
|
|
die("index file corrupt");
|
|
|
|
|
|
2009-05-23 20:53:12 +02:00
|
|
|
argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
|
2009-02-17 15:27:11 +01:00
|
|
|
ls_files_usage, 0);
|
2013-01-16 14:25:58 +01:00
|
|
|
el = add_exclude_list(&dir, EXC_CMDL, "--exclude option");
|
|
|
|
|
for (i = 0; i < exclude_list.nr; i++) {
|
|
|
|
|
add_exclude(exclude_list.items[i].string, "", 0, el, --exclude_args);
|
|
|
|
|
}
|
2009-02-17 15:27:11 +01:00
|
|
|
if (show_tag || show_valid_bit) {
|
|
|
|
|
tag_cached = "H ";
|
|
|
|
|
tag_unmerged = "M ";
|
|
|
|
|
tag_removed = "R ";
|
|
|
|
|
tag_modified = "C ";
|
|
|
|
|
tag_other = "? ";
|
|
|
|
|
tag_killed = "K ";
|
2009-08-20 15:46:57 +02:00
|
|
|
tag_skip_worktree = "S ";
|
2009-12-25 19:08:04 +01:00
|
|
|
tag_resolve_undo = "U ";
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
2009-03-20 22:30:51 +01:00
|
|
|
if (show_modified || show_others || show_deleted || (dir.flags & DIR_SHOW_IGNORED) || show_killed)
|
2009-02-17 15:27:11 +01:00
|
|
|
require_work_tree = 1;
|
|
|
|
|
if (show_unmerged)
|
|
|
|
|
/*
|
|
|
|
|
* There's no point in showing unmerged unless
|
|
|
|
|
* you also show the stage information.
|
|
|
|
|
*/
|
|
|
|
|
show_stage = 1;
|
|
|
|
|
if (dir.exclude_per_dir)
|
|
|
|
|
exc_given = 1;
|
2005-04-28 20:44:04 +02:00
|
|
|
|
2007-11-03 12:23:12 +01:00
|
|
|
if (require_work_tree && !is_inside_work_tree())
|
|
|
|
|
setup_work_tree();
|
2007-01-23 13:30:20 +01:00
|
|
|
|
2009-02-17 15:27:11 +01:00
|
|
|
pathspec = get_pathspec(prefix, argv);
|
[PATCH] git-ls-files: generalized pathspecs
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 02:27:50 +02:00
|
|
|
|
2009-04-17 20:13:30 +02:00
|
|
|
/* be nice with submodule paths ending in a slash */
|
2009-02-07 14:43:03 +01:00
|
|
|
if (pathspec)
|
|
|
|
|
strip_trailing_slash_from_submodules();
|
|
|
|
|
|
2010-06-03 15:39:18 +02:00
|
|
|
/* Find common prefix for all pathspec's */
|
2011-09-04 12:42:01 +02:00
|
|
|
max_prefix = common_prefix(pathspec);
|
2011-07-30 19:13:47 +02:00
|
|
|
max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
|
[PATCH] Make "git-ls-files" work in subdirectories
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 21:55:33 +02:00
|
|
|
|
2006-02-14 21:40:20 +01:00
|
|
|
/* Treat unmatching pathspec elements as errors */
|
|
|
|
|
if (pathspec && error_unmatch) {
|
|
|
|
|
int num;
|
|
|
|
|
for (num = 0; pathspec[num]; num++)
|
|
|
|
|
;
|
|
|
|
|
ps_matched = xcalloc(1, num);
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-09 03:53:35 +02:00
|
|
|
if ((dir.flags & DIR_SHOW_IGNORED) && !exc_given)
|
|
|
|
|
die("ls-files --ignored needs some exclude pattern");
|
2005-04-12 03:55:38 +02:00
|
|
|
|
|
|
|
|
/* With no flags, we default to showing the cached files */
|
2013-06-13 20:19:44 +02:00
|
|
|
if (!(show_stage || show_deleted || show_others || show_unmerged ||
|
|
|
|
|
show_killed || show_modified || show_resolve_undo))
|
2005-04-12 03:55:38 +02:00
|
|
|
show_cached = 1;
|
|
|
|
|
|
2010-06-03 15:39:18 +02:00
|
|
|
if (max_prefix)
|
|
|
|
|
prune_cache(max_prefix);
|
2007-09-13 01:04:22 +02:00
|
|
|
if (with_tree) {
|
|
|
|
|
/*
|
|
|
|
|
* Basic sanity check; show-stages and show-unmerged
|
|
|
|
|
* would not make any sense with this option.
|
|
|
|
|
*/
|
|
|
|
|
if (show_stage || show_unmerged)
|
|
|
|
|
die("ls-files --with-tree is incompatible with -s or -u");
|
2010-06-03 15:39:18 +02:00
|
|
|
overlay_tree_on_cache(with_tree, max_prefix);
|
2007-09-13 01:04:22 +02:00
|
|
|
}
|
2010-06-03 15:39:18 +02:00
|
|
|
show_files(&dir);
|
2009-12-25 19:08:04 +01:00
|
|
|
if (show_resolve_undo)
|
2010-06-03 15:39:18 +02:00
|
|
|
show_ru_info();
|
2006-02-14 21:40:20 +01:00
|
|
|
|
|
|
|
|
if (ps_matched) {
|
2007-11-18 10:13:32 +01:00
|
|
|
int bad;
|
2011-08-01 23:19:58 +02:00
|
|
|
bad = report_path_error(ps_matched, pathspec, prefix);
|
2007-11-18 10:13:32 +01:00
|
|
|
if (bad)
|
2006-11-30 12:28:28 +01:00
|
|
|
fprintf(stderr, "Did you forget to 'git add'?\n");
|
|
|
|
|
|
2007-11-18 10:13:32 +01:00
|
|
|
return bad ? 1 : 0;
|
2006-02-14 21:40:20 +01:00
|
|
|
}
|
|
|
|
|
|
2005-04-12 03:55:38 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|