git/builtin/ls-files.c

692 lines
19 KiB
C
Raw Normal View History

/*
* 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
*/
#define NO_THE_INDEX_COMPATIBILITY_MACROS
#include "cache.h"
#include "repository.h"
#include "config.h"
#include "quote.h"
#include "dir.h"
#include "builtin.h"
#include "tree.h"
#include "parse-options.h"
#include "resolve-undo.h"
#include "string-list.h"
#include "pathspec.h"
#include "run-command.h"
#include "submodule.h"
#include "submodule-config.h"
static int abbrev;
static int show_deleted;
static int show_cached;
static int show_others;
static int show_stage;
static int show_unmerged;
static int show_resolve_undo;
static int show_modified;
static int show_killed;
static int show_valid_bit;
static int show_fsmonitor_bit;
static int line_terminator = '\n';
static int debug_mode;
static int show_eol;
static int recurse_submodules;
static const char *prefix;
static int max_prefix_len;
static int prefix_len;
static struct pathspec pathspec;
static int error_unmatch;
static char *ps_matched;
static const char *with_tree;
static int exc_given;
static int exclude_args;
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
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 *tag_skip_worktree = "";
static const char *tag_resolve_undo = "";
static void write_eolinfo(const struct index_state *istate,
const struct cache_entry *ce, const char *path)
{
if (show_eol) {
struct stat st;
const char *i_txt = "";
const char *w_txt = "";
const char *a_txt = get_convert_attr_ascii(istate, path);
if (ce && S_ISREG(ce->ce_mode))
i_txt = get_cached_convert_stats_ascii(istate,
ce->name);
if (!lstat(path, &st) && S_ISREG(st.st_mode))
w_txt = get_wt_convert_stats_ascii(path);
printf("i/%-5s w/%-5s attr/%-17s\t", i_txt, w_txt, a_txt);
}
}
static void write_name(const char *name)
{
quote.c: substitute path_relative with relative_path Substitute the function path_relative in quote.c with the function relative_path. Function relative_path can be treated as an enhanced and more robust version of path_relative. Outputs of path_relative and it's replacement (relative_path) are the same for the following cases: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b/ c/ c/ /a/b/c /a/b/ c c /a/ /a/b/ ../ ../ / /a/b/ ../../ ../../ /a/c /a/b/ ../c ../c /x/y /a/b/ ../../x/y ../../x/y a/b/c/ a/b/ c/ c/ a/ a/b/ ../ ../ x/y a/b/ ../../x/y ../../x/y /a/b (empty) /a/b /a/b /a/b (null) /a/b /a/b a/b (empty) a/b a/b a/b (null) a/b a/b But if both of the path and the prefix are the same, or the returned relative path should be the current directory, the outputs of both functions are different. Function relative_path returns "./", while function path_relative returns empty string. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/ /a/b/ (empty) ./ a/b/ a/b/ (empty) ./ (empty) (null) (empty) ./ (empty) (empty) (empty) ./ But the callers of path_relative can handle such cases, or never encounter this issue at all, because: * In function quote_path_relative, if the output of path_relative is empty, append "./" to it, like: if (!out->len) strbuf_addstr(out, "./"); * Another caller is write_name_quoted_relative, which is only used by builtin/ls-files.c. git-ls-files only show files, so path of files will never be identical with the prefix of a directory. The following differences show that path_relative does not handle extra slashes properly: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a//b//c/ //a/b// ../../../../a//b//c/ c/ a/b//c a//b ../b//c c And if prefix has no trailing slash, path_relative does not work properly either. But since prefix always has a trailing slash, it's not a problem. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b b/c/ c/ /a/b /a/b b ./ /a/b/ /a/b b/ ./ /a /a/b/ ../../a ../ a/b/c/ a/b b/c/ c/ a/b/ a/b b/ ./ a a/b ../a ../ x/y a/b/ ../x/y ../../x/y a/c a/b c ../c /a/ /a/b (empty) ../ (empty) /a/b ../../ ./ One tricky part in this conversion is write_name() function in ls-files.c. It takes a counted string, <name, len>, that is to be made relative to <prefix, prefix_len> and then quoted. Because write_name_quoted_relative() still takes these two parameters as counted string, but ignores the count and treat these two as NUL-terminated strings, this conversion needs to be audited for its callers: - For <name, len>, all three callers of write_name() passes a NUL-terminated string and its true length, so this patch makes "len" unused. - For <prefix, prefix_len>, prefix could be a string that is longer than empty while prefix_len could be 0 when "--full-name" option is used. This is fixed by checking prefix_len in write_name() and calling write_name_quoted_relative() with NULL when prefix_len is set to 0. Again, this makes "prefix_len" given to write_name_quoted_relative() unused, without introducing a bug. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-25 23:53:44 +08:00
/*
* With "--full-name", prefix_len=0; this caller needs to pass
* an empty string in that case (a NULL is good for "").
quote.c: substitute path_relative with relative_path Substitute the function path_relative in quote.c with the function relative_path. Function relative_path can be treated as an enhanced and more robust version of path_relative. Outputs of path_relative and it's replacement (relative_path) are the same for the following cases: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b/ c/ c/ /a/b/c /a/b/ c c /a/ /a/b/ ../ ../ / /a/b/ ../../ ../../ /a/c /a/b/ ../c ../c /x/y /a/b/ ../../x/y ../../x/y a/b/c/ a/b/ c/ c/ a/ a/b/ ../ ../ x/y a/b/ ../../x/y ../../x/y /a/b (empty) /a/b /a/b /a/b (null) /a/b /a/b a/b (empty) a/b a/b a/b (null) a/b a/b But if both of the path and the prefix are the same, or the returned relative path should be the current directory, the outputs of both functions are different. Function relative_path returns "./", while function path_relative returns empty string. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/ /a/b/ (empty) ./ a/b/ a/b/ (empty) ./ (empty) (null) (empty) ./ (empty) (empty) (empty) ./ But the callers of path_relative can handle such cases, or never encounter this issue at all, because: * In function quote_path_relative, if the output of path_relative is empty, append "./" to it, like: if (!out->len) strbuf_addstr(out, "./"); * Another caller is write_name_quoted_relative, which is only used by builtin/ls-files.c. git-ls-files only show files, so path of files will never be identical with the prefix of a directory. The following differences show that path_relative does not handle extra slashes properly: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a//b//c/ //a/b// ../../../../a//b//c/ c/ a/b//c a//b ../b//c c And if prefix has no trailing slash, path_relative does not work properly either. But since prefix always has a trailing slash, it's not a problem. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b b/c/ c/ /a/b /a/b b ./ /a/b/ /a/b b/ ./ /a /a/b/ ../../a ../ a/b/c/ a/b b/c/ c/ a/b/ a/b b/ ./ a a/b ../a ../ x/y a/b/ ../x/y ../../x/y a/c a/b c ../c /a/ /a/b (empty) ../ (empty) /a/b ../../ ./ One tricky part in this conversion is write_name() function in ls-files.c. It takes a counted string, <name, len>, that is to be made relative to <prefix, prefix_len> and then quoted. Because write_name_quoted_relative() still takes these two parameters as counted string, but ignores the count and treat these two as NUL-terminated strings, this conversion needs to be audited for its callers: - For <name, len>, all three callers of write_name() passes a NUL-terminated string and its true length, so this patch makes "len" unused. - For <prefix, prefix_len>, prefix could be a string that is longer than empty while prefix_len could be 0 when "--full-name" option is used. This is fixed by checking prefix_len in write_name() and calling write_name_quoted_relative() with NULL when prefix_len is set to 0. Again, this makes "prefix_len" given to write_name_quoted_relative() unused, without introducing a bug. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-25 23:53:44 +08:00
*/
write_name_quoted_relative(name, prefix_len ? prefix : NULL,
stdout, line_terminator);
}
static const char *get_tag(const struct cache_entry *ce, const char *tag)
{
static char alttag[4];
if (tag && *tag && ((show_valid_bit && (ce->ce_flags & CE_VALID)) ||
(show_fsmonitor_bit && (ce->ce_flags & CE_FSMONITOR_VALID)))) {
memcpy(alttag, tag, 3);
if (isalpha(tag[0])) {
alttag[0] = tolower(tag[0]);
} else if (tag[0] == '?') {
alttag[0] = '!';
} else {
alttag[0] = 'v';
alttag[1] = tag[0];
alttag[2] = ' ';
alttag[3] = 0;
}
tag = alttag;
}
return tag;
}
static void print_debug(const struct cache_entry *ce)
{
if (debug_mode) {
const struct stat_data *sd = &ce->ce_stat_data;
printf(" ctime: %d:%d\n", sd->sd_ctime.sec, sd->sd_ctime.nsec);
printf(" mtime: %d:%d\n", sd->sd_mtime.sec, sd->sd_mtime.nsec);
printf(" dev: %d\tino: %d\n", sd->sd_dev, sd->sd_ino);
printf(" uid: %d\tgid: %d\n", sd->sd_uid, sd->sd_gid);
printf(" size: %d\tflags: %x\n", sd->sd_size, ce->ce_flags);
}
}
static void show_dir_entry(const struct index_state *istate,
const char *tag, struct dir_entry *ent)
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
{
int len = max_prefix_len;
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (len > ent->len)
die("git ls-files: internal error - directory entry not superset of prefix");
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (!dir_path_match(istate, ent, &pathspec, len, ps_matched))
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
return;
fputs(tag, stdout);
write_eolinfo(istate, NULL, ent->name);
write_name(ent->name);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
}
static void show_other_files(const struct index_state *istate,
const struct dir_struct *dir)
{
int i;
for (i = 0; i < dir->nr; i++) {
struct dir_entry *ent = dir->entries[i];
if (!index_name_is_other(istate, ent->name, ent->len))
continue;
show_dir_entry(istate, tag_other, ent);
}
}
static void show_killed_files(const struct index_state *istate,
const struct dir_struct *dir)
{
int i;
for (i = 0; i < dir->nr; i++) {
struct dir_entry *ent = dir->entries[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 = index_name_pos(istate, ent->name, ent->len);
if (0 <= pos)
BUG("killed-file %.*s not found",
ent->len, ent->name);
pos = -pos - 1;
while (pos < istate->cache_nr &&
ce_stage(istate->cache[pos]))
pos++; /* skip unmerged */
if (istate->cache_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(istate->cache[pos]);
if ((ent->len < len) &&
!strncmp(istate->cache[pos]->name,
ent->name, ent->len) &&
istate->cache[pos]->name[ent->len] == '/')
killed = 1;
break;
}
if (0 <= index_name_pos(istate, 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)
show_dir_entry(istate, tag_killed, dir->entries[i]);
}
}
static void show_files(struct repository *repo, struct dir_struct *dir);
static void show_submodule(struct repository *superproject,
struct dir_struct *dir, const char *path)
{
struct repository submodule;
if (repo_submodule_init(&submodule, superproject, path))
return;
if (repo_read_index(&submodule) < 0)
die("index file corrupt");
show_files(&submodule, dir);
repo_clear(&submodule);
}
static void show_ce(struct repository *repo, struct dir_struct *dir,
const struct cache_entry *ce, const char *fullname,
const char *tag)
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
{
if (max_prefix_len > strlen(fullname))
die("git ls-files: internal error - cache entry not superset of prefix");
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (recurse_submodules && S_ISGITLINK(ce->ce_mode) &&
is_submodule_active(repo, ce->name)) {
show_submodule(repo, dir, ce->name);
} else if (match_pathspec(repo->index, &pathspec, fullname, strlen(fullname),
max_prefix_len, ps_matched,
S_ISDIR(ce->ce_mode) ||
S_ISGITLINK(ce->ce_mode))) {
tag = get_tag(ce, tag);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (!show_stage) {
fputs(tag, stdout);
} else {
printf("%s%06o %s %d\t",
tag,
ce->ce_mode,
find_unique_abbrev(&ce->oid, abbrev),
ce_stage(ce));
}
write_eolinfo(repo->index, ce, fullname);
write_name(fullname);
print_debug(ce);
}
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
}
static void show_ru_info(const struct index_state *istate)
{
struct string_list_item *item;
if (!istate->resolve_undo)
return;
for_each_string_list_item(item, istate->resolve_undo) {
const char *path = item->string;
struct resolve_undo_info *ui = item->util;
int i, len;
len = strlen(path);
if (len < max_prefix_len)
continue; /* outside of the prefix */
if (!match_pathspec(istate, &pathspec, path, len,
max_prefix_len, ps_matched, 0))
continue; /* uninterested */
for (i = 0; i < 3; i++) {
if (!ui->mode[i])
continue;
printf("%s%06o %s %d\t", tag_resolve_undo, ui->mode[i],
find_unique_abbrev(&ui->oid[i], abbrev),
i + 1);
write_name(path);
}
}
}
static int ce_excluded(struct dir_struct *dir, struct index_state *istate,
const char *fullname, const struct cache_entry *ce)
{
int dtype = ce_to_dtype(ce);
return is_excluded(dir, istate, fullname, &dtype);
}
static void construct_fullname(struct strbuf *out, const struct repository *repo,
const struct cache_entry *ce)
{
strbuf_reset(out);
if (repo->submodule_prefix)
strbuf_addstr(out, repo->submodule_prefix);
strbuf_addstr(out, ce->name);
}
static void show_files(struct repository *repo, struct dir_struct *dir)
{
int i;
struct strbuf fullname = STRBUF_INIT;
/* For cached/deleted files we don't need to even do the readdir */
if (show_others || show_killed) {
ls-files -k: a directory only can be killed if the index has a non-directory "ls-files -o" and "ls-files -k" both traverse the working tree down to find either all untracked paths or those that will be "killed" (removed from the working tree to make room) when the paths recorded in the index are checked out. It is necessary to traverse the working tree fully when enumerating all the "other" paths, but when we are only interested in "killed" paths, we can take advantage of the fact that paths that do not overlap with entries in the index can never be killed. The treat_one_path() helper function, which is called during the recursive traversal, is the ideal place to implement an optimization. When we are looking at a directory P in the working tree, there are three cases: (1) P exists in the index. Everything inside the directory P in the working tree needs to go when P is checked out from the index. (2) P does not exist in the index, but there is P/Q in the index. We know P will stay a directory when we check out the contents of the index, but we do not know yet if there is a directory P/Q in the working tree to be killed, so we need to recurse. (3) P does not exist in the index, and there is no P/Q in the index to require P to be a directory, either. Only in this case, we know that everything inside P will not be killed without recursing. Note that this helper is called by treat_leading_path() that decides if we need to traverse only subdirectories of a single common leading directory, which is essential for this optimization to be correct. This caller checks each level of the leading path component from shallower directory to deeper ones, and that is what allows us to only check if the path appears in the index. If the call to treat_one_path() weren't there, given a path P/Q/R, the real traversal may start from directory P/Q/R, even when the index records P as a regular file, and we would end up having to check if any leading subpath in P/Q/R, e.g. P, appears in the index. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-16 03:13:46 +08:00
if (!show_others)
dir->flags |= DIR_COLLECT_KILLED_ONLY;
fill_directory(dir, repo->index, &pathspec);
if (show_others)
show_other_files(repo->index, dir);
if (show_killed)
show_killed_files(repo->index, dir);
}
if (show_cached || show_stage) {
for (i = 0; i < repo->index->cache_nr; i++) {
const struct cache_entry *ce = repo->index->cache[i];
construct_fullname(&fullname, repo, ce);
if ((dir->flags & DIR_SHOW_IGNORED) &&
!ce_excluded(dir, repo->index, fullname.buf, ce))
continue;
if (show_unmerged && !ce_stage(ce))
continue;
if (ce->ce_flags & CE_UPDATE)
continue;
show_ce(repo, dir, ce, fullname.buf,
ce_stage(ce) ? tag_unmerged :
(ce_skip_worktree(ce) ? tag_skip_worktree :
tag_cached));
}
}
if (show_deleted || show_modified) {
for (i = 0; i < repo->index->cache_nr; i++) {
const struct cache_entry *ce = repo->index->cache[i];
struct stat st;
int err;
construct_fullname(&fullname, repo, ce);
if ((dir->flags & DIR_SHOW_IGNORED) &&
!ce_excluded(dir, repo->index, fullname.buf, ce))
continue;
if (ce->ce_flags & CE_UPDATE)
continue;
if (ce_skip_worktree(ce))
continue;
err = lstat(fullname.buf, &st);
if (show_deleted && err)
show_ce(repo, dir, ce, fullname.buf, tag_removed);
if (show_modified && ie_modified(repo->index, ce, &st, 0))
show_ce(repo, dir, ce, fullname.buf, tag_modified);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
}
}
strbuf_release(&fullname);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
}
/*
* Prune the index to only contain stuff starting with "prefix"
*/
static void prune_index(struct index_state *istate,
const char *prefix, size_t prefixlen)
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
{
int pos;
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
unsigned int first, last;
if (!prefix || !istate->cache_nr)
return;
pos = index_name_pos(istate, prefix, prefixlen);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (pos < 0)
pos = -pos-1;
first = pos;
last = istate->cache_nr;
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
while (last > first) {
int next = (last + first) >> 1;
const struct cache_entry *ce = istate->cache[next];
if (!strncmp(ce->name, prefix, prefixlen)) {
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
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>
2005-08-22 03:55:33 +08:00
last = next;
}
MOVE_ARRAY(istate->cache, istate->cache + pos, last - pos);
istate->cache_nr = last - pos;
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
}
static int get_common_prefix_len(const char *common_prefix)
{
int common_prefix_len;
if (!common_prefix)
return 0;
common_prefix_len = strlen(common_prefix);
/*
* If the prefix has a trailing slash, strip it so that submodules wont
* be pruned from the index.
*/
if (common_prefix[common_prefix_len - 1] == '/')
common_prefix_len--;
return common_prefix_len;
}
/*
* Read the tree specified with --with-tree option
* (typically, HEAD) into stage #1 and then
* squash them down to stage #0. This is used for
* --error-unmatch to list and check the path patterns
* that were given from the command line. We are not
* going to write this index out.
*/
void overlay_tree_on_index(struct index_state *istate,
const char *tree_name, const char *prefix)
{
struct tree *tree;
struct object_id oid;
struct pathspec pathspec;
struct cache_entry *last_stage0 = NULL;
int i;
if (get_oid(tree_name, &oid))
die("tree-ish %s not found.", tree_name);
tree = parse_tree_indirect(&oid);
if (!tree)
die("bad tree-ish %s", tree_name);
/* Hoist the unmerged entries up to stage #3 to make room */
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce = istate->cache[i];
if (!ce_stage(ce))
continue;
ce->ce_flags |= CE_STAGEMASK;
}
if (prefix) {
static const char *(matchbuf[1]);
matchbuf[0] = NULL;
parse_pathspec(&pathspec, PATHSPEC_ALL_MAGIC,
PATHSPEC_PREFER_CWD, prefix, matchbuf);
} else
memset(&pathspec, 0, sizeof(pathspec));
if (read_tree(the_repository, tree, 1, &pathspec, istate))
die("unable to read tree entries %s", tree_name);
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce = istate->cache[i];
switch (ce_stage(ce)) {
case 0:
last_stage0 = ce;
/* fallthru */
default:
continue;
case 1:
/*
* If there is stage #0 entry for this, we do not
* need to show it. We use CE_UPDATE bit to mark
* such an entry.
*/
if (last_stage0 &&
!strcmp(last_stage0->name, ce->name))
ce->ce_flags |= CE_UPDATE;
}
}
}
static const char * const ls_files_usage[] = {
N_("git ls-files [<options>] [<file>...]"),
NULL
};
static int option_parse_exclude(const struct option *opt,
const char *arg, int unset)
{
struct string_list *exclude_list = opt->value;
assert NOARG/NONEG behavior of parse-options callbacks When we define a parse-options callback, the flags we put in the option struct must match what the callback expects. For example, a callback which does not handle the "unset" parameter should only be used with PARSE_OPT_NONEG. But since the callback and the option struct are not defined next to each other, it's easy to get this wrong (as earlier patches in this series show). Fortunately, the compiler can help us here: compiling with -Wunused-parameters can show us which callbacks ignore their "unset" parameters (and likewise, ones that ignore "arg" expect to be triggered with PARSE_OPT_NOARG). But after we've inspected a callback and determined that all of its callers use the right flags, what do we do next? We'd like to silence the compiler warning, but do so in a way that will catch any wrong calls in the future. We can do that by actually checking those variables and asserting that they match our expectations. Because this is such a common pattern, we'll introduce some helper macros. The resulting messages aren't as descriptive as we could make them, but the file/line information from BUG() is enough to identify the problem (and anyway, the point is that these should never be seen). Each of the annotated callbacks in this patch triggers -Wunused-parameters, and was manually inspected to make sure all callers use the correct options (so none of these BUGs should be triggerable). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 14:45:42 +08:00
BUG_ON_OPT_NEG(unset);
exc_given = 1;
string_list_append(exclude_list, arg);
return 0;
}
static int option_parse_exclude_from(const struct option *opt,
const char *arg, int unset)
{
struct dir_struct *dir = opt->value;
assert NOARG/NONEG behavior of parse-options callbacks When we define a parse-options callback, the flags we put in the option struct must match what the callback expects. For example, a callback which does not handle the "unset" parameter should only be used with PARSE_OPT_NONEG. But since the callback and the option struct are not defined next to each other, it's easy to get this wrong (as earlier patches in this series show). Fortunately, the compiler can help us here: compiling with -Wunused-parameters can show us which callbacks ignore their "unset" parameters (and likewise, ones that ignore "arg" expect to be triggered with PARSE_OPT_NOARG). But after we've inspected a callback and determined that all of its callers use the right flags, what do we do next? We'd like to silence the compiler warning, but do so in a way that will catch any wrong calls in the future. We can do that by actually checking those variables and asserting that they match our expectations. Because this is such a common pattern, we'll introduce some helper macros. The resulting messages aren't as descriptive as we could make them, but the file/line information from BUG() is enough to identify the problem (and anyway, the point is that these should never be seen). Each of the annotated callbacks in this patch triggers -Wunused-parameters, and was manually inspected to make sure all callers use the correct options (so none of these BUGs should be triggerable). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 14:45:42 +08:00
BUG_ON_OPT_NEG(unset);
exc_given = 1;
add_excludes_from_file(dir, arg);
return 0;
}
static int option_parse_exclude_standard(const struct option *opt,
const char *arg, int unset)
{
struct dir_struct *dir = opt->value;
assert NOARG/NONEG behavior of parse-options callbacks When we define a parse-options callback, the flags we put in the option struct must match what the callback expects. For example, a callback which does not handle the "unset" parameter should only be used with PARSE_OPT_NONEG. But since the callback and the option struct are not defined next to each other, it's easy to get this wrong (as earlier patches in this series show). Fortunately, the compiler can help us here: compiling with -Wunused-parameters can show us which callbacks ignore their "unset" parameters (and likewise, ones that ignore "arg" expect to be triggered with PARSE_OPT_NOARG). But after we've inspected a callback and determined that all of its callers use the right flags, what do we do next? We'd like to silence the compiler warning, but do so in a way that will catch any wrong calls in the future. We can do that by actually checking those variables and asserting that they match our expectations. Because this is such a common pattern, we'll introduce some helper macros. The resulting messages aren't as descriptive as we could make them, but the file/line information from BUG() is enough to identify the problem (and anyway, the point is that these should never be seen). Each of the annotated callbacks in this patch triggers -Wunused-parameters, and was manually inspected to make sure all callers use the correct options (so none of these BUGs should be triggerable). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 14:45:42 +08:00
BUG_ON_OPT_NEG(unset);
BUG_ON_OPT_ARG(arg);
exc_given = 1;
setup_standard_excludes(dir);
return 0;
}
int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
{
int require_work_tree = 0, show_tag = 0, i;
const char *max_prefix;
struct dir_struct dir;
struct exclude_list *el;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
struct option builtin_ls_files_options[] = {
/* Think twice before adding "--nul" synonym to this */
OPT_SET_INT('z', NULL, &line_terminator,
N_("paths are separated with NUL character"), '\0'),
OPT_BOOL('t', NULL, &show_tag,
N_("identify the file status with tags")),
OPT_BOOL('v', NULL, &show_valid_bit,
N_("use lowercase letters for 'assume unchanged' files")),
OPT_BOOL('f', NULL, &show_fsmonitor_bit,
N_("use lowercase letters for 'fsmonitor clean' files")),
OPT_BOOL('c', "cached", &show_cached,
N_("show cached files in the output (default)")),
OPT_BOOL('d', "deleted", &show_deleted,
N_("show deleted files in the output")),
OPT_BOOL('m', "modified", &show_modified,
N_("show modified files in the output")),
OPT_BOOL('o', "others", &show_others,
N_("show other files in the output")),
OPT_BIT('i', "ignored", &dir.flags,
N_("show ignored files in the output"),
DIR_SHOW_IGNORED),
OPT_BOOL('s', "stage", &show_stage,
N_("show staged contents' object name in the output")),
OPT_BOOL('k', "killed", &show_killed,
N_("show files on the filesystem that need to be removed")),
OPT_BIT(0, "directory", &dir.flags,
N_("show 'other' directories' names only"),
DIR_SHOW_OTHER_DIRECTORIES),
OPT_BOOL(0, "eol", &show_eol, N_("show line endings of files")),
OPT_NEGBIT(0, "empty-directory", &dir.flags,
N_("don't show empty directories"),
DIR_HIDE_EMPTY_DIRECTORIES),
OPT_BOOL('u', "unmerged", &show_unmerged,
N_("show unmerged files in the output")),
OPT_BOOL(0, "resolve-undo", &show_resolve_undo,
N_("show resolve-undo information")),
{ OPTION_CALLBACK, 'x', "exclude", &exclude_list, N_("pattern"),
N_("skip files matching pattern"),
PARSE_OPT_NONEG, option_parse_exclude },
{ OPTION_CALLBACK, 'X', "exclude-from", &dir, N_("file"),
N_("exclude patterns are read from <file>"),
PARSE_OPT_NONEG, option_parse_exclude_from },
OPT_STRING(0, "exclude-per-directory", &dir.exclude_per_dir, N_("file"),
N_("read additional per-directory exclude patterns in <file>")),
{ OPTION_CALLBACK, 0, "exclude-standard", &dir, NULL,
N_("add the standard git exclusions"),
PARSE_OPT_NOARG | PARSE_OPT_NONEG,
option_parse_exclude_standard },
OPT_SET_INT_F(0, "full-name", &prefix_len,
N_("make the output relative to the project top directory"),
0, PARSE_OPT_NONEG),
OPT_BOOL(0, "recurse-submodules", &recurse_submodules,
N_("recurse through submodules")),
OPT_BOOL(0, "error-unmatch", &error_unmatch,
N_("if any <file> is not in the index, treat this as an error")),
OPT_STRING(0, "with-tree", &with_tree, N_("tree-ish"),
N_("pretend that paths removed since <tree-ish> are still present")),
OPT__ABBREV(&abbrev),
OPT_BOOL(0, "debug", &debug_mode, N_("show debugging data")),
OPT_END()
};
if (argc == 2 && !strcmp(argv[1], "-h"))
usage_with_options(ls_files_usage, builtin_ls_files_options);
memset(&dir, 0, sizeof(dir));
prefix = cmd_prefix;
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (prefix)
prefix_len = strlen(prefix);
git_config(git_default_config, NULL);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
if (repo_read_index(the_repository) < 0)
die("index file corrupt");
argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
ls_files_usage, 0);
el = add_exclude_list(&dir, EXC_CMDL, "--exclude option");
for (i = 0; i < exclude_list.nr; i++) {
add_exclude(exclude_list.items[i].string, "", 0, el, --exclude_args);
}
if (show_tag || show_valid_bit || show_fsmonitor_bit) {
tag_cached = "H ";
tag_unmerged = "M ";
tag_removed = "R ";
tag_modified = "C ";
tag_other = "? ";
tag_killed = "K ";
tag_skip_worktree = "S ";
tag_resolve_undo = "U ";
}
if (show_modified || show_others || show_deleted || (dir.flags & DIR_SHOW_IGNORED) || show_killed)
require_work_tree = 1;
if (show_unmerged)
/*
* There's no point in showing unmerged unless
* you also show the stage information.
*/
show_stage = 1;
if (dir.exclude_per_dir)
exc_given = 1;
if (require_work_tree && !is_inside_work_tree())
setup_work_tree();
if (recurse_submodules &&
(show_stage || show_deleted || show_others || show_unmerged ||
show_killed || show_modified || show_resolve_undo || with_tree))
die("ls-files --recurse-submodules unsupported mode");
if (recurse_submodules && error_unmatch)
die("ls-files --recurse-submodules does not support "
"--error-unmatch");
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD,
prefix, argv);
/*
* Find common prefix for all pathspec's
* This is used as a performance optimization which unfortunately cannot
* be done when recursing into submodules because when a pathspec is
* given which spans repository boundaries you can't simply remove the
* submodule entry because the pathspec may match something inside the
* submodule.
*/
if (recurse_submodules)
max_prefix = NULL;
else
max_prefix = common_prefix(&pathspec);
max_prefix_len = get_common_prefix_len(max_prefix);
prune_index(the_repository->index, max_prefix, max_prefix_len);
[PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 03:55:33 +08:00
/* Treat unmatching pathspec elements as errors */
if (pathspec.nr && error_unmatch)
ps_matched = xcalloc(pathspec.nr, 1);
if ((dir.flags & DIR_SHOW_IGNORED) && !exc_given)
die("ls-files --ignored needs some exclude pattern");
/* With no flags, we default to showing the cached files */
if (!(show_stage || show_deleted || show_others || show_unmerged ||
show_killed || show_modified || show_resolve_undo))
show_cached = 1;
if (with_tree) {
/*
* Basic sanity check; show-stages and show-unmerged
* would not make any sense with this option.
*/
if (show_stage || show_unmerged)
die("ls-files --with-tree is incompatible with -s or -u");
overlay_tree_on_index(the_repository->index, with_tree, max_prefix);
}
show_files(the_repository, &dir);
if (show_resolve_undo)
show_ru_info(the_repository->index);
if (ps_matched) {
int bad;
bad = report_path_error(ps_matched, &pathspec, prefix);
if (bad)
fprintf(stderr, "Did you forget to 'git add'?\n");
return bad ? 1 : 0;
}
add UNLEAK annotation for reducing leak false positives It's a common pattern in git commands to allocate some memory that should last for the lifetime of the program and then not bother to free it, relying on the OS to throw it away. This keeps the code simple, and it's fast (we don't waste time traversing structures or calling free at the end of the program). But it also triggers warnings from memory-leak checkers like valgrind or LSAN. They know that the memory was still allocated at program exit, but they don't know _when_ the leaked memory stopped being useful. If it was early in the program, then it's probably a real and important leak. But if it was used right up until program exit, it's not an interesting leak and we'd like to suppress it so that we can see the real leaks. This patch introduces an UNLEAK() macro that lets us do so. To understand its design, let's first look at some of the alternatives. Unfortunately the suppression systems offered by leak-checking tools don't quite do what we want. A leak-checker basically knows two things: 1. Which blocks were allocated via malloc, and the callstack during the allocation. 2. Which blocks were left un-freed at the end of the program (and which are unreachable, but more on that later). Their suppressions work by mentioning the function or callstack of a particular allocation, and marking it as OK to leak. So imagine you have code like this: int cmd_foo(...) { /* this allocates some memory */ char *p = some_function(); printf("%s", p); return 0; } You can say "ignore allocations from some_function(), they're not leaks". But that's not right. That function may be called elsewhere, too, and we would potentially want to know about those leaks. So you can say "ignore the callstack when main calls some_function". That works, but your annotations are brittle. In this case it's only two functions, but you can imagine that the actual allocation is much deeper. If any of the intermediate code changes, you have to update the suppression. What we _really_ want to say is that "the value assigned to p at the end of the function is not a real leak". But leak-checkers can't understand that; they don't know about "p" in the first place. However, we can do something a little bit tricky if we make some assumptions about how leak-checkers work. They generally don't just report all un-freed blocks. That would report even globals which are still accessible when the leak-check is run. Instead they take some set of memory (like BSS) as a root and mark it as "reachable". Then they scan the reachable blocks for anything that looks like a pointer to a malloc'd block, and consider that block reachable. And then they scan those blocks, and so on, transitively marking anything reachable from a global as "not leaked" (or at least leaked in a different category). So we can mark the value of "p" as reachable by putting it into a variable with program lifetime. One way to do that is to just mark "p" as static. But that actually affects the run-time behavior if the function is called twice (you aren't likely to call main() twice, but some of our cmd_*() functions are called from other commands). Instead, we can trick the leak-checker by putting the value into _any_ reachable bytes. This patch keeps a global linked-list of bytes copied from "unleaked" variables. That list is reachable even at program exit, which confers recursive reachability on whatever values we unleak. In other words, you can do: int cmd_foo(...) { char *p = some_function(); printf("%s", p); UNLEAK(p); return 0; } to annotate "p" and suppress the leak report. But wait, couldn't we just say "free(p)"? In this toy example, yes. But UNLEAK()'s byte-copying strategy has several advantages over actually freeing the memory: 1. It's recursive across structures. In many cases our "p" is not just a pointer, but a complex struct whose fields may have been allocated by a sub-function. And in some cases (e.g., dir_struct) we don't even have a function which knows how to free all of the struct members. By marking the struct itself as reachable, that confers reachability on any pointers it contains (including those found in embedded structs, or reachable by walking heap blocks recursively. 2. It works on cases where we're not sure if the value is allocated or not. For example: char *p = argc > 1 ? argv[1] : some_function(); It's safe to use UNLEAK(p) here, because it's not freeing any memory. In the case that we're pointing to argv here, the reachability checker will just ignore our bytes. 3. Likewise, it works even if the variable has _already_ been freed. We're just copying the pointer bytes. If the block has been freed, the leak-checker will skip over those bytes as uninteresting. 4. Because it's not actually freeing memory, you can UNLEAK() before we are finished accessing the variable. This is helpful in cases like this: char *p = some_function(); return another_function(p); Writing this with free() requires: int ret; char *p = some_function(); ret = another_function(p); free(p); return ret; But with unleak we can just write: char *p = some_function(); UNLEAK(p); return another_function(p); This patch adds the UNLEAK() macro and enables it automatically when Git is compiled with SANITIZE=leak. In normal builds it's a noop, so we pay no runtime cost. It also adds some UNLEAK() annotations to show off how the feature works. On top of other recent leak fixes, these are enough to get t0000 and t0001 to pass when compiled with LSAN. Note the case in commit.c which actually converts a strbuf_release() into an UNLEAK. This code was already non-leaky, but the free didn't do anything useful, since we're exiting. Converting it to an annotation means that non-leak-checking builds pay no runtime cost. The cost is minimal enough that it's probably not worth going on a crusade to convert these kinds of frees to UNLEAKS. I did it here for consistency with the "sb" leak (though it would have been equally correct to go the other way, and turn them both into strbuf_release() calls). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-08 14:38:41 +08:00
UNLEAK(dir);
return 0;
}