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 <dirent.h>
|
2005-04-28 20:44:04 +02:00
|
|
|
#include <fnmatch.h>
|
2005-04-12 03:55:38 +02:00
|
|
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
|
|
|
static int show_deleted = 0;
|
|
|
|
static int show_cached = 0;
|
|
|
|
static int show_others = 0;
|
|
|
|
static int show_ignored = 0;
|
2005-04-16 17:33:23 +02:00
|
|
|
static int show_stage = 0;
|
2005-04-16 21:43:32 +02:00
|
|
|
static int show_unmerged = 0;
|
2005-05-13 02:17:54 +02:00
|
|
|
static int show_killed = 0;
|
2005-04-15 20:11:01 +02:00
|
|
|
static int line_terminator = '\n';
|
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
|
|
|
static int prefix_len = 0, prefix_offset = 0;
|
|
|
|
static const char *prefix = NULL;
|
|
|
|
static const char *glob = NULL;
|
|
|
|
|
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-04-22 04:47:08 +02:00
|
|
|
|
2005-07-25 00:26:09 +02:00
|
|
|
static char *exclude_per_dir = NULL;
|
2005-07-29 08:32:20 +02:00
|
|
|
|
|
|
|
/* We maintain three exclude pattern lists:
|
|
|
|
* EXC_CMDL lists patterns explicitly given on the command line.
|
|
|
|
* EXC_DIRS lists patterns obtained from per-directory ignore files.
|
|
|
|
* EXC_FILE lists patterns from fallback ignore files.
|
|
|
|
*/
|
|
|
|
#define EXC_CMDL 0
|
|
|
|
#define EXC_DIRS 1
|
|
|
|
#define EXC_FILE 2
|
|
|
|
static struct exclude_list {
|
|
|
|
int nr;
|
|
|
|
int alloc;
|
|
|
|
struct exclude {
|
|
|
|
const char *pattern;
|
|
|
|
const char *base;
|
|
|
|
int baselen;
|
|
|
|
} **excludes;
|
|
|
|
} exclude_list[3];
|
|
|
|
|
|
|
|
static void add_exclude(const char *string, const char *base,
|
|
|
|
int baselen, struct exclude_list *which)
|
2005-04-28 20:44:04 +02:00
|
|
|
{
|
2005-07-25 00:26:09 +02:00
|
|
|
struct exclude *x = xmalloc(sizeof (*x));
|
|
|
|
|
|
|
|
x->pattern = string;
|
|
|
|
x->base = base;
|
|
|
|
x->baselen = baselen;
|
2005-07-29 08:32:20 +02:00
|
|
|
if (which->nr == which->alloc) {
|
|
|
|
which->alloc = alloc_nr(which->alloc);
|
|
|
|
which->excludes = realloc(which->excludes,
|
|
|
|
which->alloc * sizeof(x));
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
2005-07-29 08:32:20 +02:00
|
|
|
which->excludes[which->nr++] = x;
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
|
|
|
|
2005-07-25 00:26:09 +02:00
|
|
|
static int add_excludes_from_file_1(const char *fname,
|
2005-07-29 08:32:20 +02:00
|
|
|
const char *base,
|
|
|
|
int baselen,
|
|
|
|
struct exclude_list *which)
|
2005-04-28 20:44:04 +02:00
|
|
|
{
|
|
|
|
int fd, i;
|
|
|
|
long size;
|
|
|
|
char *buf, *entry;
|
|
|
|
|
|
|
|
fd = open(fname, O_RDONLY);
|
|
|
|
if (fd < 0)
|
|
|
|
goto err;
|
|
|
|
size = lseek(fd, 0, SEEK_END);
|
|
|
|
if (size < 0)
|
|
|
|
goto err;
|
|
|
|
lseek(fd, 0, SEEK_SET);
|
|
|
|
if (size == 0) {
|
|
|
|
close(fd);
|
2005-07-25 00:26:09 +02:00
|
|
|
return 0;
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
|
|
|
buf = xmalloc(size);
|
|
|
|
if (read(fd, buf, size) != size)
|
|
|
|
goto err;
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
entry = buf;
|
|
|
|
for (i = 0; i < size; i++) {
|
|
|
|
if (buf[i] == '\n') {
|
2005-07-25 00:26:09 +02:00
|
|
|
if (entry != buf + i && entry[0] != '#') {
|
2005-04-28 20:44:04 +02:00
|
|
|
buf[i] = 0;
|
2005-07-29 08:32:20 +02:00
|
|
|
add_exclude(entry, base, baselen, which);
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
|
|
|
entry = buf + i + 1;
|
|
|
|
}
|
|
|
|
}
|
2005-07-25 00:26:09 +02:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
if (0 <= fd)
|
|
|
|
close(fd);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void add_excludes_from_file(const char *fname)
|
|
|
|
{
|
2005-07-29 08:32:20 +02:00
|
|
|
if (add_excludes_from_file_1(fname, "", 0,
|
|
|
|
&exclude_list[EXC_FILE]) < 0)
|
2005-07-25 00:26:09 +02:00
|
|
|
die("cannot use %s as an exclude file", fname);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int push_exclude_per_directory(const char *base, int baselen)
|
|
|
|
{
|
|
|
|
char exclude_file[PATH_MAX];
|
2005-07-29 08:32:20 +02:00
|
|
|
struct exclude_list *el = &exclude_list[EXC_DIRS];
|
|
|
|
int current_nr = el->nr;
|
2005-07-25 00:26:09 +02:00
|
|
|
|
|
|
|
if (exclude_per_dir) {
|
|
|
|
memcpy(exclude_file, base, baselen);
|
|
|
|
strcpy(exclude_file + baselen, exclude_per_dir);
|
2005-07-29 08:32:20 +02:00
|
|
|
add_excludes_from_file_1(exclude_file, base, baselen, el);
|
2005-07-25 00:26:09 +02:00
|
|
|
}
|
|
|
|
return current_nr;
|
|
|
|
}
|
2005-04-28 20:44:04 +02:00
|
|
|
|
2005-07-25 00:26:09 +02:00
|
|
|
static void pop_exclude_per_directory(int stk)
|
|
|
|
{
|
2005-07-29 08:32:20 +02:00
|
|
|
struct exclude_list *el = &exclude_list[EXC_DIRS];
|
|
|
|
|
|
|
|
while (stk < el->nr)
|
|
|
|
free(el->excludes[--el->nr]);
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
|
|
|
|
2005-07-29 08:32:20 +02:00
|
|
|
/* Scan the list and let the last match determines the fate.
|
|
|
|
* Return 1 for exclude, 0 for include and -1 for undecided.
|
|
|
|
*/
|
|
|
|
static int excluded_1(const char *pathname,
|
|
|
|
int pathlen,
|
|
|
|
struct exclude_list *el)
|
2005-04-28 20:44:04 +02:00
|
|
|
{
|
|
|
|
int i;
|
2005-07-25 00:26:09 +02:00
|
|
|
|
2005-07-29 08:32:20 +02:00
|
|
|
if (el->nr) {
|
|
|
|
for (i = el->nr - 1; 0 <= i; i--) {
|
|
|
|
struct exclude *x = el->excludes[i];
|
2005-07-25 00:26:09 +02:00
|
|
|
const char *exclude = x->pattern;
|
|
|
|
int to_exclude = 1;
|
|
|
|
|
|
|
|
if (*exclude == '!') {
|
|
|
|
to_exclude = 0;
|
|
|
|
exclude++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!strchr(exclude, '/')) {
|
|
|
|
/* match basename */
|
|
|
|
const char *basename = strrchr(pathname, '/');
|
|
|
|
basename = (basename) ? basename+1 : pathname;
|
|
|
|
if (fnmatch(exclude, basename, 0) == 0)
|
|
|
|
return to_exclude;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* match with FNM_PATHNAME:
|
|
|
|
* exclude has base (baselen long) inplicitly
|
|
|
|
* in front of it.
|
|
|
|
*/
|
|
|
|
int baselen = x->baselen;
|
|
|
|
if (*exclude == '/')
|
|
|
|
exclude++;
|
|
|
|
|
|
|
|
if (pathlen < baselen ||
|
|
|
|
(baselen && pathname[baselen-1] != '/') ||
|
|
|
|
strncmp(pathname, x->base, baselen))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (fnmatch(exclude, pathname+baselen,
|
|
|
|
FNM_PATHNAME) == 0)
|
|
|
|
return to_exclude;
|
|
|
|
}
|
|
|
|
}
|
2005-04-28 20:44:04 +02:00
|
|
|
}
|
2005-07-29 08:32:20 +02:00
|
|
|
return -1; /* undecided */
|
|
|
|
}
|
|
|
|
|
|
|
|
static int excluded(const char *pathname)
|
|
|
|
{
|
|
|
|
int pathlen = strlen(pathname);
|
|
|
|
int st;
|
|
|
|
|
|
|
|
for (st = EXC_CMDL; st <= EXC_FILE; st++) {
|
|
|
|
switch (excluded_1(pathname, pathlen, &exclude_list[st])) {
|
|
|
|
case 0:
|
|
|
|
return 0;
|
|
|
|
case 1:
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
2005-04-28 20:44:04 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-05-13 02:17:54 +02:00
|
|
|
struct nond_on_fs {
|
|
|
|
int len;
|
|
|
|
char name[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct nond_on_fs **dir;
|
2005-04-12 03:55:38 +02:00
|
|
|
static int nr_dir;
|
|
|
|
static int dir_alloc;
|
|
|
|
|
|
|
|
static void add_name(const char *pathname, int len)
|
|
|
|
{
|
2005-05-13 02:17:54 +02:00
|
|
|
struct nond_on_fs *ent;
|
2005-04-12 03:55:38 +02:00
|
|
|
|
|
|
|
if (cache_name_pos(pathname, len) >= 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (nr_dir == dir_alloc) {
|
|
|
|
dir_alloc = alloc_nr(dir_alloc);
|
2005-05-13 02:17:54 +02:00
|
|
|
dir = xrealloc(dir, dir_alloc*sizeof(ent));
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
2005-05-13 02:17:54 +02:00
|
|
|
ent = xmalloc(sizeof(*ent) + len + 1);
|
|
|
|
ent->len = len;
|
|
|
|
memcpy(ent->name, pathname, 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
|
|
|
ent->name[len] = 0;
|
2005-05-13 02:17:54 +02:00
|
|
|
dir[nr_dir++] = ent;
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read a directory tree. We currently ignore anything but
|
2005-05-13 02:16:04 +02:00
|
|
|
* directories, regular files and symlinks. That's because git
|
|
|
|
* doesn't handle them at all yet. Maybe that will change some
|
|
|
|
* day.
|
2005-04-12 03:55:38 +02:00
|
|
|
*
|
2005-07-25 00:26:09 +02:00
|
|
|
* Also, we ignore the name ".git" (even if it is not a directory).
|
2005-04-12 20:36:26 +02:00
|
|
|
* That likely will not change.
|
2005-04-12 03:55:38 +02:00
|
|
|
*/
|
|
|
|
static void read_directory(const char *path, const char *base, int baselen)
|
|
|
|
{
|
|
|
|
DIR *dir = opendir(path);
|
|
|
|
|
|
|
|
if (dir) {
|
2005-07-25 00:26:09 +02:00
|
|
|
int exclude_stk;
|
2005-04-12 03:55:38 +02:00
|
|
|
struct dirent *de;
|
|
|
|
char fullname[MAXPATHLEN + 1];
|
|
|
|
memcpy(fullname, base, baselen);
|
|
|
|
|
2005-07-25 00:26:09 +02:00
|
|
|
exclude_stk = push_exclude_per_directory(base, baselen);
|
|
|
|
|
2005-04-12 03:55:38 +02:00
|
|
|
while ((de = readdir(dir)) != NULL) {
|
|
|
|
int len;
|
|
|
|
|
2005-05-25 03:20:08 +02:00
|
|
|
if ((de->d_name[0] == '.') &&
|
|
|
|
(de->d_name[1] == 0 ||
|
|
|
|
!strcmp(de->d_name + 1, ".") ||
|
|
|
|
!strcmp(de->d_name + 1, "git")))
|
2005-04-12 03:55:38 +02:00
|
|
|
continue;
|
|
|
|
len = strlen(de->d_name);
|
|
|
|
memcpy(fullname + baselen, de->d_name, len+1);
|
2005-07-25 00:26:09 +02:00
|
|
|
if (excluded(fullname) != show_ignored)
|
|
|
|
continue;
|
2005-04-12 03:55:38 +02:00
|
|
|
|
2005-04-30 18:51:03 +02:00
|
|
|
switch (DTYPE(de)) {
|
2005-04-12 03:55:38 +02:00
|
|
|
struct stat st;
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
case DT_UNKNOWN:
|
|
|
|
if (lstat(fullname, &st))
|
|
|
|
continue;
|
2005-05-13 02:16:04 +02:00
|
|
|
if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode))
|
2005-04-12 03:55:38 +02:00
|
|
|
break;
|
|
|
|
if (!S_ISDIR(st.st_mode))
|
|
|
|
continue;
|
|
|
|
/* fallthrough */
|
|
|
|
case DT_DIR:
|
|
|
|
memcpy(fullname + baselen + len, "/", 2);
|
2005-04-22 04:47:08 +02:00
|
|
|
read_directory(fullname, fullname,
|
|
|
|
baselen + len + 1);
|
2005-04-12 03:55:38 +02:00
|
|
|
continue;
|
|
|
|
case DT_REG:
|
2005-05-13 02:16:04 +02:00
|
|
|
case DT_LNK:
|
2005-04-12 03:55:38 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
add_name(fullname, baselen + len);
|
|
|
|
}
|
|
|
|
closedir(dir);
|
2005-07-25 00:26:09 +02:00
|
|
|
|
|
|
|
pop_exclude_per_directory(exclude_stk);
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cmp_name(const void *p1, const void *p2)
|
|
|
|
{
|
2005-05-13 02:17:54 +02:00
|
|
|
const struct nond_on_fs *e1 = *(const struct nond_on_fs **)p1;
|
|
|
|
const struct nond_on_fs *e2 = *(const struct nond_on_fs **)p2;
|
|
|
|
|
|
|
|
return cache_name_compare(e1->name, e1->len,
|
|
|
|
e2->name, e2->len);
|
|
|
|
}
|
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
|
|
|
static void show_dir_entry(const char *tag, struct nond_on_fs *ent)
|
|
|
|
{
|
|
|
|
int len = prefix_len;
|
|
|
|
int offset = prefix_offset;
|
|
|
|
|
|
|
|
if (len >= ent->len)
|
|
|
|
die("git-ls-files: internal error - directory entry not superset of prefix");
|
|
|
|
|
|
|
|
if (glob && fnmatch(glob, ent->name + len, 0))
|
|
|
|
return;
|
|
|
|
|
|
|
|
printf("%s%s%c", tag, ent->name + offset, line_terminator);
|
|
|
|
}
|
|
|
|
|
2005-05-20 20:46:10 +02:00
|
|
|
static void show_killed_files(void)
|
2005-05-13 02:17:54 +02:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < nr_dir; i++) {
|
|
|
|
struct nond_on_fs *ent = dir[i];
|
|
|
|
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)
|
[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
|
|
|
show_dir_entry(tag_killed, dir[i]);
|
2005-05-13 02:17:54 +02:00
|
|
|
}
|
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
|
|
|
static void show_ce_entry(const char *tag, struct cache_entry *ce)
|
|
|
|
{
|
|
|
|
int len = prefix_len;
|
|
|
|
int offset = prefix_offset;
|
|
|
|
|
|
|
|
if (len >= ce_namelen(ce))
|
|
|
|
die("git-ls-files: internal error - cache entry not superset of prefix");
|
|
|
|
|
|
|
|
if (glob && fnmatch(glob, ce->name + len, 0))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!show_stage)
|
|
|
|
printf("%s%s%c", tag, ce->name + offset, line_terminator);
|
|
|
|
else
|
|
|
|
printf("%s%06o %s %d\t%s%c",
|
|
|
|
tag,
|
|
|
|
ntohl(ce->ce_mode),
|
|
|
|
sha1_to_hex(ce->sha1),
|
|
|
|
ce_stage(ce),
|
|
|
|
ce->name + offset, line_terminator);
|
|
|
|
}
|
|
|
|
|
2005-04-12 03:55:38 +02:00
|
|
|
static void show_files(void)
|
|
|
|
{
|
|
|
|
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) {
|
[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
|
|
|
const char *path = ".", *base = "";
|
|
|
|
int baselen = prefix_len;
|
|
|
|
|
|
|
|
if (baselen)
|
|
|
|
path = base = prefix;
|
|
|
|
read_directory(path, base, baselen);
|
2005-05-13 02:17:54 +02:00
|
|
|
qsort(dir, nr_dir, sizeof(struct nond_on_fs *), cmp_name);
|
|
|
|
if (show_others)
|
|
|
|
for (i = 0; i < nr_dir; i++)
|
[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
|
|
|
show_dir_entry(tag_other, dir[i]);
|
2005-05-13 02:17:54 +02:00
|
|
|
if (show_killed)
|
|
|
|
show_killed_files();
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
2005-04-16 17:33:23 +02:00
|
|
|
if (show_cached | show_stage) {
|
2005-04-12 03:55:38 +02:00
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
2005-04-28 20:44:04 +02:00
|
|
|
if (excluded(ce->name) != show_ignored)
|
|
|
|
continue;
|
2005-04-16 21:43:32 +02:00
|
|
|
if (show_unmerged && !ce_stage(ce))
|
|
|
|
continue;
|
[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
|
|
|
show_ce_entry(ce_stage(ce) ? tag_unmerged : tag_cached, ce);
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (show_deleted) {
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
struct stat st;
|
2005-04-28 20:44:04 +02:00
|
|
|
if (excluded(ce->name) != show_ignored)
|
|
|
|
continue;
|
2005-05-05 14:38:25 +02:00
|
|
|
if (!lstat(ce->name, &st))
|
2005-04-12 03:55:38 +02:00
|
|
|
continue;
|
[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
|
|
|
show_ce_entry(tag_removed, ce);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prune the index to only contain stuff starting with "prefix"
|
|
|
|
*/
|
|
|
|
static void prune_cache(void)
|
|
|
|
{
|
|
|
|
int pos = cache_name_pos(prefix, prefix_len);
|
|
|
|
unsigned int first, last;
|
|
|
|
|
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos-1;
|
|
|
|
active_cache += pos;
|
|
|
|
active_nr -= pos;
|
|
|
|
first = 0;
|
|
|
|
last = active_nr;
|
|
|
|
while (last > first) {
|
|
|
|
int next = (last + first) >> 1;
|
|
|
|
struct cache_entry *ce = active_cache[next];
|
|
|
|
if (!strncmp(ce->name, prefix, prefix_len)) {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the glob starts with a subdirectory, append it to
|
|
|
|
* the prefix instead, for more efficient operation.
|
|
|
|
*
|
|
|
|
* But we do not update the "prefix_offset", which tells
|
|
|
|
* how much of the name to ignore at printout.
|
|
|
|
*/
|
|
|
|
static void extend_prefix(void)
|
|
|
|
{
|
|
|
|
const char *p, *slash;
|
|
|
|
char c;
|
|
|
|
|
|
|
|
p = glob;
|
|
|
|
slash = NULL;
|
|
|
|
while ((c = *p++) != '\0') {
|
|
|
|
if (c == '*')
|
|
|
|
break;
|
|
|
|
if (c == '/')
|
|
|
|
slash = p;
|
|
|
|
}
|
|
|
|
if (slash) {
|
|
|
|
int len = slash - glob;
|
|
|
|
char *newprefix = xmalloc(len + prefix_len + 1);
|
|
|
|
memcpy(newprefix, prefix, prefix_len);
|
|
|
|
memcpy(newprefix + prefix_len, glob, len);
|
|
|
|
prefix_len += len;
|
|
|
|
newprefix[prefix_len] = 0;
|
|
|
|
prefix = newprefix;
|
|
|
|
glob = *slash ? slash : NULL;
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-07-29 11:01:26 +02:00
|
|
|
static const char ls_files_usage[] =
|
2005-05-19 13:17:16 +02:00
|
|
|
"git-ls-files [-z] [-t] (--[cached|deleted|others|stage|unmerged|killed])* "
|
2005-07-25 00:26:09 +02:00
|
|
|
"[ --ignored ] [--exclude=<pattern>] [--exclude-from=<file>] "
|
|
|
|
"[ --exclude-per-directory=<filename> ]";
|
2005-04-29 00:06:25 +02:00
|
|
|
|
2005-04-12 03:55:38 +02:00
|
|
|
int main(int argc, char **argv)
|
|
|
|
{
|
|
|
|
int i;
|
2005-07-29 08:32:20 +02:00
|
|
|
int exc_given = 0;
|
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
|
|
|
prefix = setup_git_directory();
|
|
|
|
if (prefix)
|
|
|
|
prefix_offset = prefix_len = strlen(prefix);
|
|
|
|
|
2005-04-12 03:55:38 +02:00
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
char *arg = argv[i];
|
|
|
|
|
2005-04-15 20:11:01 +02:00
|
|
|
if (!strcmp(arg, "-z")) {
|
|
|
|
line_terminator = 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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-t")) {
|
2005-04-22 04:47:08 +02:00
|
|
|
tag_cached = "H ";
|
|
|
|
tag_unmerged = "M ";
|
|
|
|
tag_removed = "R ";
|
|
|
|
tag_other = "? ";
|
2005-05-13 02:17:54 +02:00
|
|
|
tag_killed = "K ";
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-c") || !strcmp(arg, "--cached")) {
|
2005-04-12 03:55:38 +02:00
|
|
|
show_cached = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-d") || !strcmp(arg, "--deleted")) {
|
2005-04-12 03:55:38 +02:00
|
|
|
show_deleted = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-o") || !strcmp(arg, "--others")) {
|
2005-04-12 03:55:38 +02:00
|
|
|
show_others = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-i") || !strcmp(arg, "--ignored")) {
|
2005-04-12 03:55:38 +02:00
|
|
|
show_ignored = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-s") || !strcmp(arg, "--stage")) {
|
2005-04-16 17:33:23 +02:00
|
|
|
show_stage = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-k") || !strcmp(arg, "--killed")) {
|
2005-05-13 02:17:54 +02:00
|
|
|
show_killed = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-u") || !strcmp(arg, "--unmerged")) {
|
2005-04-22 04:47:08 +02:00
|
|
|
/* There's no point in showing unmerged unless
|
|
|
|
* you also show the stage information.
|
|
|
|
*/
|
2005-04-16 21:43:32 +02:00
|
|
|
show_stage = 1;
|
|
|
|
show_unmerged = 1;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-x") && i+1 < argc) {
|
2005-07-29 08:32:20 +02:00
|
|
|
exc_given = 1;
|
|
|
|
add_exclude(argv[++i], "", 0, &exclude_list[EXC_CMDL]);
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--exclude=", 10)) {
|
2005-07-29 08:32:20 +02:00
|
|
|
exc_given = 1;
|
|
|
|
add_exclude(arg+10, "", 0, &exclude_list[EXC_CMDL]);
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-X") && i+1 < argc) {
|
2005-07-29 08:32:20 +02:00
|
|
|
exc_given = 1;
|
2005-04-28 20:44:04 +02:00
|
|
|
add_excludes_from_file(argv[++i]);
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--exclude-from=", 15)) {
|
2005-07-29 08:32:20 +02:00
|
|
|
exc_given = 1;
|
2005-04-28 20:44:04 +02:00
|
|
|
add_excludes_from_file(arg+15);
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--exclude-per-directory=", 24)) {
|
2005-07-29 08:32:20 +02:00
|
|
|
exc_given = 1;
|
2005-07-25 00:26:09 +02:00
|
|
|
exclude_per_dir = arg + 24;
|
[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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--full-name")) {
|
|
|
|
prefix_offset = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (glob || *arg == '-')
|
2005-04-30 22:59:38 +02:00
|
|
|
usage(ls_files_usage);
|
[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
|
|
|
glob = arg;
|
2005-04-28 20:44:04 +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
|
|
|
if (glob)
|
|
|
|
extend_prefix();
|
|
|
|
|
2005-07-29 08:32:20 +02:00
|
|
|
if (show_ignored && !exc_given) {
|
2005-04-22 04:47:08 +02:00
|
|
|
fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
|
|
|
|
argv[0]);
|
2005-04-28 20:44:04 +02:00
|
|
|
exit(1);
|
2005-04-12 03:55:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* With no flags, we default to showing the cached files */
|
2005-05-13 02:17:54 +02:00
|
|
|
if (!(show_stage | show_deleted | show_others | show_unmerged | show_killed))
|
2005-04-12 03:55:38 +02:00
|
|
|
show_cached = 1;
|
|
|
|
|
|
|
|
read_cache();
|
[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)
|
|
|
|
prune_cache();
|
2005-04-12 03:55:38 +02:00
|
|
|
show_files();
|
|
|
|
return 0;
|
|
|
|
}
|