|
|
|
/*
|
|
|
|
* 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>
|
|
|
|
#include <fnmatch.h>
|
|
|
|
|
|
|
|
#include "cache.h"
|
|
|
|
#include "quote.h"
|
|
|
|
|
|
|
|
static int show_deleted = 0;
|
|
|
|
static int show_cached = 0;
|
|
|
|
static int show_others = 0;
|
|
|
|
static int show_ignored = 0;
|
|
|
|
static int show_stage = 0;
|
|
|
|
static int show_unmerged = 0;
|
|
|
|
static int show_modified = 0;
|
|
|
|
static int show_killed = 0;
|
|
|
|
static int line_terminator = '\n';
|
|
|
|
|
[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>
20 years ago
|
|
|
static int prefix_len = 0, prefix_offset = 0;
|
|
|
|
static const char *prefix = NULL;
|
[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>
20 years ago
|
|
|
static const char **pathspec = 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>
20 years ago
|
|
|
|
|
|
|
static const char *tag_cached = "";
|
|
|
|
static const char *tag_unmerged = "";
|
|
|
|
static const char *tag_removed = "";
|
|
|
|
static const char *tag_other = "";
|
|
|
|
static const char *tag_killed = "";
|
|
|
|
static const char *tag_modified = "";
|
|
|
|
|
|
|
|
static const char *exclude_per_dir = NULL;
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
{
|
|
|
|
struct exclude *x = xmalloc(sizeof (*x));
|
|
|
|
|
|
|
|
x->pattern = string;
|
|
|
|
x->base = base;
|
|
|
|
x->baselen = baselen;
|
|
|
|
if (which->nr == which->alloc) {
|
|
|
|
which->alloc = alloc_nr(which->alloc);
|
|
|
|
which->excludes = realloc(which->excludes,
|
|
|
|
which->alloc * sizeof(x));
|
|
|
|
}
|
|
|
|
which->excludes[which->nr++] = x;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int add_excludes_from_file_1(const char *fname,
|
|
|
|
const char *base,
|
|
|
|
int baselen,
|
|
|
|
struct exclude_list *which)
|
|
|
|
{
|
|
|
|
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);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
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') {
|
|
|
|
if (entry != buf + i && entry[0] != '#') {
|
|
|
|
buf[i - (i && buf[i-1] == '\r')] = 0;
|
|
|
|
add_exclude(entry, base, baselen, which);
|
|
|
|
}
|
|
|
|
entry = buf + i + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
if (0 <= fd)
|
|
|
|
close(fd);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void add_excludes_from_file(const char *fname)
|
|
|
|
{
|
|
|
|
if (add_excludes_from_file_1(fname, "", 0,
|
|
|
|
&exclude_list[EXC_FILE]) < 0)
|
|
|
|
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];
|
|
|
|
struct exclude_list *el = &exclude_list[EXC_DIRS];
|
|
|
|
int current_nr = el->nr;
|
|
|
|
|
|
|
|
if (exclude_per_dir) {
|
|
|
|
memcpy(exclude_file, base, baselen);
|
|
|
|
strcpy(exclude_file + baselen, exclude_per_dir);
|
|
|
|
add_excludes_from_file_1(exclude_file, base, baselen, el);
|
|
|
|
}
|
|
|
|
return current_nr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pop_exclude_per_directory(int stk)
|
|
|
|
{
|
|
|
|
struct exclude_list *el = &exclude_list[EXC_DIRS];
|
|
|
|
|
|
|
|
while (stk < el->nr)
|
|
|
|
free(el->excludes[--el->nr]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (el->nr) {
|
|
|
|
for (i = el->nr - 1; 0 <= i; i--) {
|
|
|
|
struct exclude *x = el->excludes[i];
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct nond_on_fs {
|
|
|
|
int len;
|
|
|
|
char name[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct nond_on_fs **dir;
|
|
|
|
static int nr_dir;
|
|
|
|
static int dir_alloc;
|
|
|
|
|
|
|
|
static void add_name(const char *pathname, int len)
|
|
|
|
{
|
|
|
|
struct nond_on_fs *ent;
|
|
|
|
|
|
|
|
if (cache_name_pos(pathname, len) >= 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (nr_dir == dir_alloc) {
|
|
|
|
dir_alloc = alloc_nr(dir_alloc);
|
|
|
|
dir = xrealloc(dir, dir_alloc*sizeof(ent));
|
|
|
|
}
|
|
|
|
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>
20 years ago
|
|
|
ent->name[len] = 0;
|
|
|
|
dir[nr_dir++] = ent;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read a directory tree. We currently ignore anything but
|
|
|
|
* directories, regular files and symlinks. That's because git
|
|
|
|
* doesn't handle them at all yet. Maybe that will change some
|
|
|
|
* day.
|
|
|
|
*
|
|
|
|
* Also, we ignore the name ".git" (even if it is not a directory).
|
|
|
|
* That likely will not change.
|
|
|
|
*/
|
|
|
|
static void read_directory(const char *path, const char *base, int baselen)
|
|
|
|
{
|
|
|
|
DIR *dir = opendir(path);
|
|
|
|
|
|
|
|
if (dir) {
|
|
|
|
int exclude_stk;
|
|
|
|
struct dirent *de;
|
|
|
|
char fullname[MAXPATHLEN + 1];
|
|
|
|
memcpy(fullname, base, baselen);
|
|
|
|
|
|
|
|
exclude_stk = push_exclude_per_directory(base, baselen);
|
|
|
|
|
|
|
|
while ((de = readdir(dir)) != NULL) {
|
|
|
|
int len;
|
|
|
|
|
|
|
|
if ((de->d_name[0] == '.') &&
|
|
|
|
(de->d_name[1] == 0 ||
|
|
|
|
!strcmp(de->d_name + 1, ".") ||
|
|
|
|
!strcmp(de->d_name + 1, "git")))
|
|
|
|
continue;
|
|
|
|
len = strlen(de->d_name);
|
|
|
|
memcpy(fullname + baselen, de->d_name, len+1);
|
|
|
|
if (excluded(fullname) != show_ignored)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
switch (DTYPE(de)) {
|
|
|
|
struct stat st;
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
case DT_UNKNOWN:
|
|
|
|
if (lstat(fullname, &st))
|
|
|
|
continue;
|
|
|
|
if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode))
|
|
|
|
break;
|
|
|
|
if (!S_ISDIR(st.st_mode))
|
|
|
|
continue;
|
|
|
|
/* fallthrough */
|
|
|
|
case DT_DIR:
|
|
|
|
memcpy(fullname + baselen + len, "/", 2);
|
|
|
|
read_directory(fullname, fullname,
|
|
|
|
baselen + len + 1);
|
|
|
|
continue;
|
|
|
|
case DT_REG:
|
|
|
|
case DT_LNK:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
add_name(fullname, baselen + len);
|
|
|
|
}
|
|
|
|
closedir(dir);
|
|
|
|
|
|
|
|
pop_exclude_per_directory(exclude_stk);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cmp_name(const void *p1, const void *p2)
|
|
|
|
{
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
[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>
20 years ago
|
|
|
/*
|
|
|
|
* Match a pathspec against a filename. The first "len" characters
|
|
|
|
* are the common prefix
|
|
|
|
*/
|
|
|
|
static int match(const char **spec, const char *filename, int len)
|
|
|
|
{
|
|
|
|
const char *m;
|
|
|
|
|
|
|
|
while ((m = *spec++) != NULL) {
|
|
|
|
int matchlen = strlen(m + len);
|
|
|
|
|
|
|
|
if (!matchlen)
|
|
|
|
return 1;
|
|
|
|
if (!strncmp(m + len, filename + len, matchlen)) {
|
|
|
|
if (m[len + matchlen - 1] == '/')
|
|
|
|
return 1;
|
|
|
|
switch (filename[len + matchlen]) {
|
|
|
|
case '/': case '\0':
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!fnmatch(m + len, filename + len, 0))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 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>
20 years ago
|
|
|
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");
|
|
|
|
|
[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>
20 years ago
|
|
|
if (pathspec && !match(pathspec, ent->name, 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>
20 years ago
|
|
|
return;
|
|
|
|
|
|
|
|
fputs(tag, stdout);
|
|
|
|
write_name_quoted("", ent->name + offset, line_terminator, stdout);
|
|
|
|
putchar(line_terminator);
|
[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>
20 years ago
|
|
|
}
|
|
|
|
|
|
|
|
static void show_other_files(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < nr_dir; i++) {
|
|
|
|
/* We should not have a matching entry, but we
|
|
|
|
* may have an unmerged entry for this path.
|
|
|
|
*/
|
|
|
|
struct nond_on_fs *ent = dir[i];
|
|
|
|
int pos = cache_name_pos(ent->name, ent->len);
|
|
|
|
struct cache_entry *ce;
|
|
|
|
if (0 <= pos)
|
|
|
|
die("bug in show-other-files");
|
|
|
|
pos = -pos - 1;
|
|
|
|
if (pos < active_nr) {
|
|
|
|
ce = active_cache[pos];
|
|
|
|
if (ce_namelen(ce) == ent->len &&
|
|
|
|
!memcmp(ce->name, ent->name, ent->len))
|
|
|
|
continue; /* Yup, this one exists unmerged */
|
|
|
|
}
|
|
|
|
show_dir_entry(tag_other, ent);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void show_killed_files(void)
|
|
|
|
{
|
|
|
|
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>
20 years ago
|
|
|
show_dir_entry(tag_killed, 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>
20 years ago
|
|
|
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");
|
|
|
|
|
[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>
20 years ago
|
|
|
if (pathspec && !match(pathspec, ce->name, 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>
20 years ago
|
|
|
return;
|
|
|
|
|
|
|
|
if (!show_stage) {
|
|
|
|
fputs(tag, stdout);
|
|
|
|
write_name_quoted("", ce->name + offset, line_terminator, stdout);
|
|
|
|
putchar(line_terminator);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
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>
20 years ago
|
|
|
tag,
|
|
|
|
ntohl(ce->ce_mode),
|
|
|
|
sha1_to_hex(ce->sha1),
|
|
|
|
ce_stage(ce));
|
|
|
|
write_name_quoted("", ce->name + offset, line_terminator, stdout);
|
|
|
|
putchar(line_terminator);
|
|
|
|
}
|
[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>
20 years ago
|
|
|
}
|
|
|
|
|
|
|
|
static void show_files(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* For cached/deleted files we don't need to even do the readdir */
|
|
|
|
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>
20 years ago
|
|
|
const char *path = ".", *base = "";
|
|
|
|
int baselen = prefix_len;
|
|
|
|
|
|
|
|
if (baselen)
|
|
|
|
path = base = prefix;
|
|
|
|
read_directory(path, base, baselen);
|
|
|
|
qsort(dir, nr_dir, sizeof(struct nond_on_fs *), cmp_name);
|
|
|
|
if (show_others)
|
|
|
|
show_other_files();
|
|
|
|
if (show_killed)
|
|
|
|
show_killed_files();
|
|
|
|
}
|
|
|
|
if (show_cached | show_stage) {
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
if (excluded(ce->name) != show_ignored)
|
|
|
|
continue;
|
|
|
|
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>
20 years ago
|
|
|
show_ce_entry(ce_stage(ce) ? tag_unmerged : tag_cached, ce);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (show_deleted | show_modified) {
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
struct stat st;
|
|
|
|
int err;
|
|
|
|
if (excluded(ce->name) != show_ignored)
|
|
|
|
continue;
|
|
|
|
err = lstat(ce->name, &st);
|
|
|
|
if (show_deleted && err)
|
|
|
|
show_ce_entry(tag_removed, ce);
|
|
|
|
if (show_modified && ce_modified(ce, &st))
|
|
|
|
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>
20 years ago
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
[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>
20 years ago
|
|
|
last = next;
|
|
|
|
}
|
|
|
|
active_nr = last;
|
|
|
|
}
|
|
|
|
|
[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>
20 years ago
|
|
|
static void verify_pathspec(void)
|
[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>
20 years ago
|
|
|
{
|
[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>
20 years ago
|
|
|
const char **p, *n, *prev;
|
|
|
|
char *real_prefix;
|
|
|
|
unsigned long max;
|
|
|
|
|
|
|
|
prev = NULL;
|
|
|
|
max = PATH_MAX;
|
|
|
|
for (p = pathspec; (n = *p) != NULL; p++) {
|
|
|
|
int i, len = 0;
|
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
char c = n[i];
|
|
|
|
if (prev && prev[i] != c)
|
|
|
|
break;
|
|
|
|
if (!c || c == '*' || c == '?')
|
[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>
20 years ago
|
|
|
break;
|
|
|
|
if (c == '/')
|
|
|
|
len = i+1;
|
|
|
|
}
|
|
|
|
prev = n;
|
|
|
|
if (len < max) {
|
|
|
|
max = len;
|
|
|
|
if (!max)
|
|
|
|
break;
|
|
|
|
}
|
[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>
20 years ago
|
|
|
}
|
[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>
20 years ago
|
|
|
|
|
|
|
if (prefix_offset > max || memcmp(prev, prefix, prefix_offset))
|
|
|
|
die("git-ls-files: cannot generate relative filenames containing '..'");
|
|
|
|
|
|
|
|
real_prefix = NULL;
|
|
|
|
prefix_len = max;
|
|
|
|
if (max) {
|
|
|
|
real_prefix = xmalloc(max + 1);
|
|
|
|
memcpy(real_prefix, prev, max);
|
|
|
|
real_prefix[max] = 0;
|
|
|
|
}
|
[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>
20 years ago
|
|
|
prefix = real_prefix;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char ls_files_usage[] =
|
|
|
|
"git-ls-files [-z] [-t] (--[cached|deleted|others|stage|unmerged|killed|modified])* "
|
|
|
|
"[ --ignored ] [--exclude=<pattern>] [--exclude-from=<file>] "
|
|
|
|
"[ --exclude-per-directory=<filename> ] [--] [<file>]*";
|
|
|
|
|
|
|
|
int main(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int exc_given = 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>
20 years ago
|
|
|
prefix = setup_git_directory();
|
|
|
|
if (prefix)
|
[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>
20 years ago
|
|
|
prefix_offset = strlen(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>
20 years ago
|
|
|
|
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
const char *arg = argv[i];
|
|
|
|
|
|
|
|
if (!strcmp(arg, "--")) {
|
|
|
|
i++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-t")) {
|
|
|
|
tag_cached = "H ";
|
|
|
|
tag_unmerged = "M ";
|
|
|
|
tag_removed = "R ";
|
|
|
|
tag_modified = "C ";
|
|
|
|
tag_other = "? ";
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-c") || !strcmp(arg, "--cached")) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-d") || !strcmp(arg, "--deleted")) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-m") || !strcmp(arg, "--modified")) {
|
|
|
|
show_modified = 1;
|
|
|
|
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>
20 years ago
|
|
|
if (!strcmp(arg, "-o") || !strcmp(arg, "--others")) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-i") || !strcmp(arg, "--ignored")) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-s") || !strcmp(arg, "--stage")) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-k") || !strcmp(arg, "--killed")) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-u") || !strcmp(arg, "--unmerged")) {
|
|
|
|
/* There's no point in showing unmerged unless
|
|
|
|
* you also show the stage information.
|
|
|
|
*/
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-x") && i+1 < argc) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--exclude=", 10)) {
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-X") && i+1 < argc) {
|
|
|
|
exc_given = 1;
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--exclude-from=", 15)) {
|
|
|
|
exc_given = 1;
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--exclude-per-directory=", 24)) {
|
|
|
|
exc_given = 1;
|
|
|
|
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>
20 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--full-name")) {
|
|
|
|
prefix_offset = 0;
|
|
|
|
continue;
|
|
|
|
}
|
[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>
20 years ago
|
|
|
if (*arg == '-')
|
|
|
|
usage(ls_files_usage);
|
[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>
20 years ago
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
[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>
20 years ago
|
|
|
pathspec = get_pathspec(prefix, argv + i);
|
|
|
|
|
|
|
|
/* Verify that the pathspec matches the prefix */
|
|
|
|
if (pathspec)
|
|
|
|
verify_pathspec();
|
[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>
20 years ago
|
|
|
|
|
|
|
if (show_ignored && !exc_given) {
|
|
|
|
fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
|
|
|
|
argv[0]);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* With no flags, we default to showing the cached files */
|
|
|
|
if (!(show_stage | show_deleted | show_others | show_unmerged |
|
|
|
|
show_killed | show_modified))
|
|
|
|
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>
20 years ago
|
|
|
if (prefix)
|
|
|
|
prune_cache();
|
|
|
|
show_files();
|
|
|
|
return 0;
|
|
|
|
}
|