2005-04-12 01:55:38 +00:00
|
|
|
/*
|
|
|
|
* This merges the file listing in the directory cache index
|
|
|
|
* with the actual working directory list, and shows different
|
|
|
|
* combinations of the two.
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*/
|
2023-05-16 06:33:57 +00:00
|
|
|
#include "builtin.h"
|
2017-06-22 18:43:48 +00:00
|
|
|
#include "repository.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2023-04-11 03:00:40 +00:00
|
|
|
#include "convert.h"
|
2005-10-15 04:56:46 +00:00
|
|
|
#include "quote.h"
|
2006-05-17 02:02:14 +00:00
|
|
|
#include "dir.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2023-04-11 07:41:49 +00:00
|
|
|
#include "object-name.h"
|
2022-07-23 06:44:45 +00:00
|
|
|
#include "strbuf.h"
|
2007-09-12 23:04:22 +00:00
|
|
|
#include "tree.h"
|
2021-03-20 22:37:46 +00:00
|
|
|
#include "cache-tree.h"
|
2009-02-17 14:27:11 +00:00
|
|
|
#include "parse-options.h"
|
2009-12-25 18:08:04 +00:00
|
|
|
#include "resolve-undo.h"
|
|
|
|
#include "string-list.h"
|
2023-05-16 06:33:59 +00:00
|
|
|
#include "path.h"
|
2013-07-14 08:35:25 +00:00
|
|
|
#include "pathspec.h"
|
2023-05-16 06:33:56 +00:00
|
|
|
#include "read-cache.h"
|
2016-10-07 18:18:49 +00:00
|
|
|
#include "run-command.h"
|
2023-03-21 06:26:05 +00:00
|
|
|
#include "setup.h"
|
2023-05-16 06:33:51 +00:00
|
|
|
#include "sparse-index.h"
|
2017-04-13 17:12:23 +00:00
|
|
|
#include "submodule.h"
|
2017-08-03 18:19:57 +00:00
|
|
|
#include "submodule-config.h"
|
2023-05-23 09:00:18 +00:00
|
|
|
#include "object-store.h"
|
|
|
|
#include "hex.h"
|
|
|
|
|
2005-04-12 01:55:38 +00:00
|
|
|
|
2006-08-15 17:23:48 +00:00
|
|
|
static int abbrev;
|
|
|
|
static int show_deleted;
|
|
|
|
static int show_cached;
|
|
|
|
static int show_others;
|
|
|
|
static int show_stage;
|
|
|
|
static int show_unmerged;
|
2009-12-25 18:08:04 +00:00
|
|
|
static int show_resolve_undo;
|
2006-08-15 17:23:48 +00:00
|
|
|
static int show_modified;
|
|
|
|
static int show_killed;
|
|
|
|
static int show_valid_bit;
|
2017-09-22 16:35:42 +00:00
|
|
|
static int show_fsmonitor_bit;
|
2005-04-15 18:11:01 +00:00
|
|
|
static int line_terminator = '\n';
|
2010-07-30 22:35:59 +00:00
|
|
|
static int debug_mode;
|
2016-01-16 06:50:02 +00:00
|
|
|
static int show_eol;
|
2016-10-07 18:18:49 +00:00
|
|
|
static int recurse_submodules;
|
2021-01-23 10:20:10 +00:00
|
|
|
static int skipping_duplicates;
|
2021-12-22 14:20:53 +00:00
|
|
|
static int show_sparse_dirs;
|
2005-04-12 01:55:38 +00:00
|
|
|
|
2010-06-03 13:39:18 +00:00
|
|
|
static const char *prefix;
|
|
|
|
static int max_prefix_len;
|
2006-08-15 17:23:48 +00:00
|
|
|
static int prefix_len;
|
2013-07-14 08:35:43 +00:00
|
|
|
static struct pathspec pathspec;
|
2006-08-15 17:23:48 +00:00
|
|
|
static int error_unmatch;
|
|
|
|
static char *ps_matched;
|
2007-09-12 23:04:22 +00:00
|
|
|
static const char *with_tree;
|
2009-02-17 14:27:11 +00:00
|
|
|
static int exc_given;
|
2013-01-06 16:58:04 +00:00
|
|
|
static int exclude_args;
|
2022-07-23 06:44:45 +00:00
|
|
|
static const char *format;
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
|
2005-04-22 02:47:08 +00:00
|
|
|
static const char *tag_cached = "";
|
|
|
|
static const char *tag_unmerged = "";
|
|
|
|
static const char *tag_removed = "";
|
|
|
|
static const char *tag_other = "";
|
2005-05-13 00:17:54 +00:00
|
|
|
static const char *tag_killed = "";
|
2005-09-19 22:11:15 +00:00
|
|
|
static const char *tag_modified = "";
|
2009-08-20 13:46:57 +00:00
|
|
|
static const char *tag_skip_worktree = "";
|
2009-12-25 18:08:04 +00:00
|
|
|
static const char *tag_resolve_undo = "";
|
2005-04-22 02:47:08 +00:00
|
|
|
|
2021-04-01 01:49:39 +00:00
|
|
|
static void write_eolinfo(struct index_state *istate,
|
2017-06-12 22:13:59 +00:00
|
|
|
const struct cache_entry *ce, const char *path)
|
2016-01-16 06:50:02 +00:00
|
|
|
{
|
2017-06-12 22:13:59 +00:00
|
|
|
if (show_eol) {
|
2016-01-16 06:50:02 +00:00
|
|
|
struct stat st;
|
|
|
|
const char *i_txt = "";
|
|
|
|
const char *w_txt = "";
|
2018-08-13 16:14:24 +00:00
|
|
|
const char *a_txt = get_convert_attr_ascii(istate, path);
|
2016-01-16 06:50:02 +00:00
|
|
|
if (ce && S_ISREG(ce->ce_mode))
|
2017-06-12 22:13:59 +00:00
|
|
|
i_txt = get_cached_convert_stats_ascii(istate,
|
2017-06-12 22:13:52 +00:00
|
|
|
ce->name);
|
2016-01-16 06:50:02 +00:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-25 15:53:46 +00:00
|
|
|
static void write_name(const char *name)
|
2010-06-03 13:39:18 +00:00
|
|
|
{
|
quote.c: substitute path_relative with relative_path
Substitute the function path_relative in quote.c with the function
relative_path. Function relative_path can be treated as an enhanced
and more robust version of path_relative.
Outputs of path_relative and it's replacement (relative_path) are the
same for the following cases:
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/c/ /a/b/ c/ c/
/a/b/c /a/b/ c c
/a/ /a/b/ ../ ../
/ /a/b/ ../../ ../../
/a/c /a/b/ ../c ../c
/x/y /a/b/ ../../x/y ../../x/y
a/b/c/ a/b/ c/ c/
a/ a/b/ ../ ../
x/y a/b/ ../../x/y ../../x/y
/a/b (empty) /a/b /a/b
/a/b (null) /a/b /a/b
a/b (empty) a/b a/b
a/b (null) a/b a/b
But if both of the path and the prefix are the same, or the returned
relative path should be the current directory, the outputs of both
functions are different. Function relative_path returns "./", while
function path_relative returns empty string.
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/ /a/b/ (empty) ./
a/b/ a/b/ (empty) ./
(empty) (null) (empty) ./
(empty) (empty) (empty) ./
But the callers of path_relative can handle such cases, or never
encounter this issue at all, because:
* In function quote_path_relative, if the output of path_relative is
empty, append "./" to it, like:
if (!out->len)
strbuf_addstr(out, "./");
* Another caller is write_name_quoted_relative, which is only used
by builtin/ls-files.c. git-ls-files only show files, so path of
files will never be identical with the prefix of a directory.
The following differences show that path_relative does not handle
extra slashes properly:
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a//b//c/ //a/b// ../../../../a//b//c/ c/
a/b//c a//b ../b//c c
And if prefix has no trailing slash, path_relative does not work
properly either. But since prefix always has a trailing slash, it's
not a problem.
path prefix output of path_relative output of relative_path
======== ========= ======================= =======================
/a/b/c/ /a/b b/c/ c/
/a/b /a/b b ./
/a/b/ /a/b b/ ./
/a /a/b/ ../../a ../
a/b/c/ a/b b/c/ c/
a/b/ a/b b/ ./
a a/b ../a ../
x/y a/b/ ../x/y ../../x/y
a/c a/b c ../c
/a/ /a/b (empty) ../
(empty) /a/b ../../ ./
One tricky part in this conversion is write_name() function in
ls-files.c. It takes a counted string, <name, len>, that is to be
made relative to <prefix, prefix_len> and then quoted. Because
write_name_quoted_relative() still takes these two parameters as
counted string, but ignores the count and treat these two as
NUL-terminated strings, this conversion needs to be audited for its
callers:
- For <name, len>, all three callers of write_name() passes a
NUL-terminated string and its true length, so this patch makes
"len" unused.
- For <prefix, prefix_len>, prefix could be a string that is longer
than empty while prefix_len could be 0 when "--full-name" option
is used. This is fixed by checking prefix_len in write_name()
and calling write_name_quoted_relative() with NULL when
prefix_len is set to 0. Again, this makes "prefix_len" given to
write_name_quoted_relative() unused, without introducing a bug.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-25 15:53:44 +00:00
|
|
|
/*
|
2013-06-25 15:53:46 +00: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 15:53:44 +00:00
|
|
|
*/
|
2013-06-25 15:53:46 +00:00
|
|
|
write_name_quoted_relative(name, prefix_len ? prefix : NULL,
|
|
|
|
stdout, line_terminator);
|
2010-06-03 13:39:18 +00:00
|
|
|
}
|
|
|
|
|
2022-07-23 06:44:45 +00:00
|
|
|
static void write_name_to_buf(struct strbuf *sb, const char *name)
|
|
|
|
{
|
2023-03-10 13:04:33 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
const char *rel = relative_path(name, prefix_len ? prefix : NULL, &buf);
|
2022-07-23 06:44:45 +00:00
|
|
|
|
|
|
|
if (line_terminator)
|
|
|
|
quote_c_style(rel, sb, NULL, 0);
|
|
|
|
else
|
|
|
|
strbuf_addstr(sb, rel);
|
2023-03-10 13:04:33 +00:00
|
|
|
|
|
|
|
strbuf_release(&buf);
|
2022-07-23 06:44:45 +00:00
|
|
|
}
|
|
|
|
|
2017-06-12 22:14:08 +00:00
|
|
|
static const char *get_tag(const struct cache_entry *ce, const char *tag)
|
|
|
|
{
|
|
|
|
static char alttag[4];
|
|
|
|
|
2017-09-22 16:35:42 +00:00
|
|
|
if (tag && *tag && ((show_valid_bit && (ce->ce_flags & CE_VALID)) ||
|
|
|
|
(show_fsmonitor_bit && (ce->ce_flags & CE_FSMONITOR_VALID)))) {
|
2017-06-12 22:14:08 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2017-06-12 22:14:07 +00:00
|
|
|
static void print_debug(const struct cache_entry *ce)
|
|
|
|
{
|
|
|
|
if (debug_mode) {
|
|
|
|
const struct stat_data *sd = &ce->ce_stat_data;
|
|
|
|
|
2019-04-07 18:47:51 +00:00
|
|
|
printf(" ctime: %u:%u\n", sd->sd_ctime.sec, sd->sd_ctime.nsec);
|
|
|
|
printf(" mtime: %u:%u\n", sd->sd_mtime.sec, sd->sd_mtime.nsec);
|
|
|
|
printf(" dev: %u\tino: %u\n", sd->sd_dev, sd->sd_ino);
|
|
|
|
printf(" uid: %u\tgid: %u\n", sd->sd_uid, sd->sd_gid);
|
|
|
|
printf(" size: %u\tflags: %x\n", sd->sd_size, ce->ce_flags);
|
2017-06-12 22:14:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-01 01:49:39 +00:00
|
|
|
static void show_dir_entry(struct index_state *istate,
|
2018-08-13 16:14:24 +00:00
|
|
|
const char *tag, struct dir_entry *ent)
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
{
|
2010-06-03 13:39:18 +00:00
|
|
|
int len = max_prefix_len;
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
|
2017-05-11 22:04:25 +00:00
|
|
|
if (len > ent->len)
|
2008-08-31 16:39:19 +00:00
|
|
|
die("git ls-files: internal error - directory entry not superset of prefix");
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
|
Fix error-prone fill_directory() API; make it only return matches
Traditionally, the expected calling convention for the dir.c API was:
fill_directory(&dir, ..., pathspec)
foreach entry in dir->entries:
if (dir_path_match(entry, pathspec))
process_or_display(entry)
This may have made sense once upon a time, because the fill_directory() call
could use cheap checks to avoid doing full pathspec matching, and an external
caller may have wanted to do other post-processing of the results anyway.
However:
* this structure makes it easy for users of the API to get it wrong
* this structure actually makes it harder to understand
fill_directory() and the functions it uses internally. It has
tripped me up several times while trying to fix bugs and
restructure things.
* relying on post-filtering was already found to produce wrong
results; pathspec matching had to be added internally for multiple
cases in order to get the right results (see commits 404ebceda01c
(dir: also check directories for matching pathspecs, 2019-09-17)
and 89a1f4aaf765 (dir: if our pathspec might match files under a
dir, recurse into it, 2019-09-17))
* it's bad for performance: fill_directory() already has to do lots
of checks and knows the subset of cases where it still needs to do
more checks. Forcing external callers to do full pathspec
matching means they must re-check _every_ path.
So, add the pathspec matching within the fill_directory() internals, and
remove it from external callers.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-01 04:17:45 +00:00
|
|
|
/* If ps_matches is non-NULL, figure out which pathspec(s) match. */
|
|
|
|
if (ps_matched)
|
|
|
|
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-21 19:55:33 +00:00
|
|
|
|
2005-10-15 04:56:46 +00:00
|
|
|
fputs(tag, stdout);
|
2018-08-13 16:14:24 +00:00
|
|
|
write_eolinfo(istate, NULL, ent->name);
|
2013-06-25 15:53:46 +00:00
|
|
|
write_name(ent->name);
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
}
|
|
|
|
|
2021-04-01 01:49:39 +00:00
|
|
|
static void show_other_files(struct index_state *istate,
|
2017-06-12 22:14:01 +00:00
|
|
|
const struct dir_struct *dir)
|
2005-11-07 01:26:31 +00:00
|
|
|
{
|
|
|
|
int i;
|
2007-04-14 23:22:08 +00:00
|
|
|
|
2006-05-17 02:02:14 +00:00
|
|
|
for (i = 0; i < dir->nr; i++) {
|
|
|
|
struct dir_entry *ent = dir->entries[i];
|
2017-06-12 22:14:01 +00:00
|
|
|
if (!index_name_is_other(istate, ent->name, ent->len))
|
2008-10-16 15:07:26 +00:00
|
|
|
continue;
|
2018-08-13 16:14:24 +00:00
|
|
|
show_dir_entry(istate, tag_other, ent);
|
2005-11-07 01:26:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-01 01:49:39 +00:00
|
|
|
static void show_killed_files(struct index_state *istate,
|
2017-06-12 22:14:00 +00:00
|
|
|
const struct dir_struct *dir)
|
2005-05-13 00:17:54 +00:00
|
|
|
{
|
|
|
|
int i;
|
2006-05-17 02:02:14 +00:00
|
|
|
for (i = 0; i < dir->nr; i++) {
|
|
|
|
struct dir_entry *ent = dir->entries[i];
|
2005-05-13 00:17:54 +00:00
|
|
|
char *cp, *sp;
|
|
|
|
int pos, len, killed = 0;
|
|
|
|
|
|
|
|
for (cp = ent->name; cp - ent->name < ent->len; cp = sp + 1) {
|
|
|
|
sp = strchr(cp, '/');
|
|
|
|
if (!sp) {
|
|
|
|
/* If ent->name is prefix of an entry in the
|
|
|
|
* cache, it will be killed.
|
|
|
|
*/
|
2017-06-12 22:14:00 +00:00
|
|
|
pos = index_name_pos(istate, ent->name, ent->len);
|
2005-05-13 00:17:54 +00:00
|
|
|
if (0 <= pos)
|
2018-05-02 09:38:39 +00:00
|
|
|
BUG("killed-file %.*s not found",
|
2016-07-26 16:05:50 +00:00
|
|
|
ent->len, ent->name);
|
2005-05-13 00:17:54 +00:00
|
|
|
pos = -pos - 1;
|
2017-06-12 22:14:00 +00:00
|
|
|
while (pos < istate->cache_nr &&
|
|
|
|
ce_stage(istate->cache[pos]))
|
2005-05-13 00:17:54 +00:00
|
|
|
pos++; /* skip unmerged */
|
2017-06-12 22:14:00 +00:00
|
|
|
if (istate->cache_nr <= pos)
|
2005-05-13 00:17:54 +00:00
|
|
|
break;
|
|
|
|
/* pos points at a name immediately after
|
|
|
|
* ent->name in the cache. Does it expect
|
|
|
|
* ent->name to be a directory?
|
|
|
|
*/
|
2017-06-12 22:14:00 +00:00
|
|
|
len = ce_namelen(istate->cache[pos]);
|
2005-05-13 00:17:54 +00:00
|
|
|
if ((ent->len < len) &&
|
2017-06-12 22:14:00 +00:00
|
|
|
!strncmp(istate->cache[pos]->name,
|
2005-05-13 00:17:54 +00:00
|
|
|
ent->name, ent->len) &&
|
2017-06-12 22:14:00 +00:00
|
|
|
istate->cache[pos]->name[ent->len] == '/')
|
2005-05-13 00:17:54 +00:00
|
|
|
killed = 1;
|
|
|
|
break;
|
|
|
|
}
|
2017-06-12 22:14:00 +00:00
|
|
|
if (0 <= index_name_pos(istate, ent->name, sp - ent->name)) {
|
2005-05-13 00:17:54 +00:00
|
|
|
/* If any of the leading directories in
|
|
|
|
* ent->name is registered in the cache,
|
|
|
|
* ent->name will be killed.
|
|
|
|
*/
|
|
|
|
killed = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (killed)
|
2018-08-13 16:14:24 +00:00
|
|
|
show_dir_entry(istate, tag_killed, dir->entries[i]);
|
2005-05-13 00:17:54 +00:00
|
|
|
}
|
2005-04-12 01:55:38 +00:00
|
|
|
}
|
|
|
|
|
2017-06-22 18:43:48 +00:00
|
|
|
static void show_files(struct repository *repo, struct dir_struct *dir);
|
2016-10-07 18:18:50 +00:00
|
|
|
|
2017-06-22 18:43:48 +00:00
|
|
|
static void show_submodule(struct repository *superproject,
|
|
|
|
struct dir_struct *dir, const char *path)
|
2016-10-07 18:18:49 +00:00
|
|
|
{
|
2018-11-29 00:27:53 +00:00
|
|
|
struct repository subrepo;
|
2017-06-22 18:43:48 +00:00
|
|
|
|
2021-09-09 18:47:28 +00:00
|
|
|
if (repo_submodule_init(&subrepo, superproject, path, null_oid()))
|
2017-06-22 18:43:48 +00:00
|
|
|
return;
|
|
|
|
|
2018-11-29 00:27:53 +00:00
|
|
|
if (repo_read_index(&subrepo) < 0)
|
2017-06-22 18:43:48 +00:00
|
|
|
die("index file corrupt");
|
|
|
|
|
2018-11-29 00:27:53 +00:00
|
|
|
show_files(&subrepo, dir);
|
2017-06-22 18:43:48 +00:00
|
|
|
|
2018-11-29 00:27:53 +00:00
|
|
|
repo_clear(&subrepo);
|
2016-10-07 18:18:49 +00:00
|
|
|
}
|
|
|
|
|
2023-05-23 09:00:18 +00:00
|
|
|
static void expand_objectsize(struct strbuf *line, const struct object_id *oid,
|
|
|
|
const enum object_type type, unsigned int padded)
|
|
|
|
{
|
|
|
|
if (type == OBJ_BLOB) {
|
|
|
|
unsigned long size;
|
|
|
|
if (oid_object_info(the_repository, oid, &size) < 0)
|
|
|
|
die(_("could not get object info about '%s'"),
|
|
|
|
oid_to_hex(oid));
|
|
|
|
if (padded)
|
|
|
|
strbuf_addf(line, "%7"PRIuMAX, (uintmax_t)size);
|
|
|
|
else
|
|
|
|
strbuf_addf(line, "%"PRIuMAX, (uintmax_t)size);
|
|
|
|
} else if (padded) {
|
|
|
|
strbuf_addf(line, "%7s", "-");
|
|
|
|
} else {
|
|
|
|
strbuf_addstr(line, "-");
|
|
|
|
}
|
|
|
|
}
|
2022-07-23 06:44:45 +00:00
|
|
|
|
|
|
|
static void show_ce_fmt(struct repository *repo, const struct cache_entry *ce,
|
|
|
|
const char *format, const char *fullname) {
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
2023-06-17 20:43:17 +00:00
|
|
|
while (strbuf_expand_step(&sb, &format)) {
|
|
|
|
const char *end;
|
|
|
|
size_t len;
|
|
|
|
struct stat st;
|
|
|
|
|
|
|
|
if (skip_prefix(format, "%", &format))
|
|
|
|
strbuf_addch(&sb, '%');
|
2023-06-17 20:44:00 +00:00
|
|
|
else if ((len = strbuf_expand_literal(&sb, format)))
|
2023-06-17 20:43:17 +00:00
|
|
|
format += len;
|
|
|
|
else if (*format != '(')
|
|
|
|
die(_("bad ls-files format: element '%s' "
|
|
|
|
"does not start with '('"), format);
|
|
|
|
else if (!(end = strchr(format + 1, ')')))
|
|
|
|
die(_("bad ls-files format: element '%s' "
|
|
|
|
"does not end in ')'"), format);
|
|
|
|
else if (skip_prefix(format, "(objectmode)", &format))
|
|
|
|
strbuf_addf(&sb, "%06o", ce->ce_mode);
|
|
|
|
else if (skip_prefix(format, "(objectname)", &format))
|
|
|
|
strbuf_add_unique_abbrev(&sb, &ce->oid, abbrev);
|
|
|
|
else if (skip_prefix(format, "(objecttype)", &format))
|
|
|
|
strbuf_addstr(&sb, type_name(object_type(ce->ce_mode)));
|
|
|
|
else if (skip_prefix(format, "(objectsize:padded)", &format))
|
|
|
|
expand_objectsize(&sb, &ce->oid,
|
|
|
|
object_type(ce->ce_mode), 1);
|
|
|
|
else if (skip_prefix(format, "(objectsize)", &format))
|
|
|
|
expand_objectsize(&sb, &ce->oid,
|
|
|
|
object_type(ce->ce_mode), 0);
|
|
|
|
else if (skip_prefix(format, "(stage)", &format))
|
|
|
|
strbuf_addf(&sb, "%d", ce_stage(ce));
|
|
|
|
else if (skip_prefix(format, "(eolinfo:index)", &format))
|
|
|
|
strbuf_addstr(&sb, S_ISREG(ce->ce_mode) ?
|
|
|
|
get_cached_convert_stats_ascii(repo->index,
|
|
|
|
ce->name) : "");
|
|
|
|
else if (skip_prefix(format, "(eolinfo:worktree)", &format))
|
|
|
|
strbuf_addstr(&sb, !lstat(fullname, &st) &&
|
|
|
|
S_ISREG(st.st_mode) ?
|
|
|
|
get_wt_convert_stats_ascii(fullname) : "");
|
|
|
|
else if (skip_prefix(format, "(eolattr)", &format))
|
|
|
|
strbuf_addstr(&sb, get_convert_attr_ascii(repo->index,
|
|
|
|
fullname));
|
|
|
|
else if (skip_prefix(format, "(path)", &format))
|
|
|
|
write_name_to_buf(&sb, fullname);
|
|
|
|
else
|
|
|
|
die(_("bad ls-files format: %%%.*s"),
|
|
|
|
(int)(end - format + 1), format);
|
|
|
|
}
|
2022-07-23 06:44:45 +00:00
|
|
|
strbuf_addch(&sb, line_terminator);
|
|
|
|
fwrite(sb.buf, sb.len, 1, stdout);
|
|
|
|
strbuf_release(&sb);
|
|
|
|
}
|
|
|
|
|
2017-06-22 18:43:48 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
{
|
2017-06-22 18:43:48 +00:00
|
|
|
if (max_prefix_len > strlen(fullname))
|
2008-08-31 16:39:19 +00:00
|
|
|
die("git ls-files: internal error - cache entry not superset of prefix");
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
|
2016-10-07 18:18:51 +00:00
|
|
|
if (recurse_submodules && S_ISGITLINK(ce->ce_mode) &&
|
2017-06-22 18:43:48 +00:00
|
|
|
is_submodule_active(repo, ce->name)) {
|
|
|
|
show_submodule(repo, dir, ce->name);
|
2018-08-13 16:14:24 +00:00
|
|
|
} else if (match_pathspec(repo->index, &pathspec, fullname, strlen(fullname),
|
2017-06-22 18:43:48 +00:00
|
|
|
max_prefix_len, ps_matched,
|
2016-10-07 18:18:49 +00:00
|
|
|
S_ISDIR(ce->ce_mode) ||
|
|
|
|
S_ISGITLINK(ce->ce_mode))) {
|
2022-07-23 06:44:45 +00:00
|
|
|
if (format) {
|
|
|
|
show_ce_fmt(repo, ce, format, fullname);
|
|
|
|
print_debug(ce);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-06-12 22:14:08 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
|
2016-10-07 18:18:49 +00:00
|
|
|
if (!show_stage) {
|
|
|
|
fputs(tag, stdout);
|
|
|
|
} else {
|
|
|
|
printf("%s%06o %s %d\t",
|
|
|
|
tag,
|
|
|
|
ce->ce_mode,
|
2022-02-24 00:23:03 +00:00
|
|
|
repo_find_unique_abbrev(repo, &ce->oid, abbrev),
|
2016-10-07 18:18:49 +00:00
|
|
|
ce_stage(ce));
|
|
|
|
}
|
2017-06-22 18:43:48 +00:00
|
|
|
write_eolinfo(repo->index, ce, fullname);
|
|
|
|
write_name(fullname);
|
2017-06-12 22:14:07 +00:00
|
|
|
print_debug(ce);
|
2006-02-09 05:50:18 +00:00
|
|
|
}
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
}
|
|
|
|
|
2021-04-01 01:49:39 +00:00
|
|
|
static void show_ru_info(struct index_state *istate)
|
2009-12-25 18:08:04 +00:00
|
|
|
{
|
2010-07-03 12:41:54 +00:00
|
|
|
struct string_list_item *item;
|
|
|
|
|
2017-06-12 22:14:02 +00:00
|
|
|
if (!istate->resolve_undo)
|
2009-12-25 18:08:04 +00:00
|
|
|
return;
|
2010-07-03 12:41:54 +00:00
|
|
|
|
2017-06-12 22:14:02 +00:00
|
|
|
for_each_string_list_item(item, istate->resolve_undo) {
|
2010-07-03 12:41:54 +00:00
|
|
|
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 */
|
2018-08-13 16:14:24 +00:00
|
|
|
if (!match_pathspec(istate, &pathspec, path, len,
|
2014-01-24 13:40:33 +00:00
|
|
|
max_prefix_len, ps_matched, 0))
|
2010-07-03 12:41:54 +00:00
|
|
|
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],
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &ui->oid[i], abbrev),
|
2010-07-03 12:41:54 +00:00
|
|
|
i + 1);
|
2013-06-25 15:53:46 +00:00
|
|
|
write_name(path);
|
2010-07-03 12:41:54 +00:00
|
|
|
}
|
|
|
|
}
|
2009-12-25 18:08:04 +00:00
|
|
|
}
|
|
|
|
|
2017-06-12 22:14:03 +00:00
|
|
|
static int ce_excluded(struct dir_struct *dir, struct index_state *istate,
|
2017-06-22 18:43:48 +00:00
|
|
|
const char *fullname, const struct cache_entry *ce)
|
2012-06-06 04:17:52 +00:00
|
|
|
{
|
|
|
|
int dtype = ce_to_dtype(ce);
|
2017-06-22 18:43:48 +00:00
|
|
|
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);
|
2012-06-06 04:17:52 +00:00
|
|
|
}
|
|
|
|
|
2017-06-22 18:43:48 +00:00
|
|
|
static void show_files(struct repository *repo, struct dir_struct *dir)
|
2005-04-12 01:55:38 +00:00
|
|
|
{
|
|
|
|
int i;
|
2017-06-22 18:43:48 +00:00
|
|
|
struct strbuf fullname = STRBUF_INIT;
|
2005-04-12 01:55:38 +00:00
|
|
|
|
|
|
|
/* For cached/deleted files we don't need to even do the readdir */
|
2005-05-13 00:17:54 +00:00
|
|
|
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-15 19:13:46 +00:00
|
|
|
if (!show_others)
|
|
|
|
dir->flags |= DIR_COLLECT_KILLED_ONLY;
|
2017-06-22 18:43:48 +00:00
|
|
|
fill_directory(dir, repo->index, &pathspec);
|
2005-05-13 00:17:54 +00:00
|
|
|
if (show_others)
|
2017-06-22 18:43:48 +00:00
|
|
|
show_other_files(repo->index, dir);
|
2005-05-13 00:17:54 +00:00
|
|
|
if (show_killed)
|
2017-06-22 18:43:48 +00:00
|
|
|
show_killed_files(repo->index, dir);
|
2005-04-12 01:55:38 +00:00
|
|
|
}
|
2017-06-22 18:43:48 +00:00
|
|
|
|
2021-01-23 10:20:09 +00:00
|
|
|
if (!(show_cached || show_stage || show_deleted || show_modified))
|
|
|
|
return;
|
2021-12-22 14:20:53 +00:00
|
|
|
|
|
|
|
if (!show_sparse_dirs)
|
|
|
|
ensure_full_index(repo->index);
|
|
|
|
|
2021-01-23 10:20:09 +00:00
|
|
|
for (i = 0; i < repo->index->cache_nr; i++) {
|
|
|
|
const struct cache_entry *ce = repo->index->cache[i];
|
|
|
|
struct stat st;
|
|
|
|
int stat_err;
|
2017-06-22 18:43:48 +00:00
|
|
|
|
2021-01-23 10:20:09 +00:00
|
|
|
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 ((show_cached || show_stage) &&
|
2021-01-23 10:20:10 +00:00
|
|
|
(!show_unmerged || ce_stage(ce))) {
|
2017-06-22 18:43:48 +00:00
|
|
|
show_ce(repo, dir, ce, fullname.buf,
|
|
|
|
ce_stage(ce) ? tag_unmerged :
|
|
|
|
(ce_skip_worktree(ce) ? tag_skip_worktree :
|
|
|
|
tag_cached));
|
2021-01-23 10:20:10 +00:00
|
|
|
if (skipping_duplicates)
|
|
|
|
goto skip_to_next_name;
|
|
|
|
}
|
2017-06-22 18:43:48 +00:00
|
|
|
|
2021-01-23 10:20:09 +00:00
|
|
|
if (!(show_deleted || show_modified))
|
|
|
|
continue;
|
|
|
|
if (ce_skip_worktree(ce))
|
|
|
|
continue;
|
|
|
|
stat_err = lstat(fullname.buf, &st);
|
|
|
|
if (stat_err && (errno != ENOENT && errno != ENOTDIR))
|
|
|
|
error_errno("cannot lstat '%s'", fullname.buf);
|
2021-01-23 10:20:10 +00:00
|
|
|
if (stat_err && show_deleted) {
|
2021-01-23 10:20:09 +00:00
|
|
|
show_ce(repo, dir, ce, fullname.buf, tag_removed);
|
2021-01-23 10:20:10 +00:00
|
|
|
if (skipping_duplicates)
|
|
|
|
goto skip_to_next_name;
|
|
|
|
}
|
2021-01-23 10:20:09 +00:00
|
|
|
if (show_modified &&
|
2021-01-23 10:20:10 +00:00
|
|
|
(stat_err || ie_modified(repo->index, ce, &st, 0))) {
|
2021-01-23 10:20:09 +00:00
|
|
|
show_ce(repo, dir, ce, fullname.buf, tag_modified);
|
2021-01-23 10:20:10 +00:00
|
|
|
if (skipping_duplicates)
|
|
|
|
goto skip_to_next_name;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
|
|
|
|
skip_to_next_name:
|
|
|
|
{
|
|
|
|
int j;
|
|
|
|
struct cache_entry **cache = repo->index->cache;
|
|
|
|
for (j = i + 1; j < repo->index->cache_nr; j++)
|
|
|
|
if (strcmp(ce->name, cache[j]->name))
|
|
|
|
break;
|
|
|
|
i = j - 1; /* compensate for the for loop */
|
|
|
|
}
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
}
|
2017-06-22 18:43:48 +00: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-21 19:55:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prune the index to only contain stuff starting with "prefix"
|
|
|
|
*/
|
2017-06-12 22:14:04 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
{
|
2017-02-10 19:42:28 +00: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-21 19:55:33 +00:00
|
|
|
unsigned int first, last;
|
|
|
|
|
2017-07-16 11:16:01 +00:00
|
|
|
if (!prefix || !istate->cache_nr)
|
2017-02-10 19:42:28 +00:00
|
|
|
return;
|
2017-06-12 22:14:04 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos-1;
|
2017-02-10 20:03:30 +00:00
|
|
|
first = pos;
|
2017-06-12 22:14:04 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
while (last > first) {
|
2019-06-13 17:51:56 +00:00
|
|
|
int next = first + ((last - first) >> 1);
|
2017-06-12 22:14:04 +00:00
|
|
|
const struct cache_entry *ce = istate->cache[next];
|
2017-02-10 19:42:28 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
first = next+1;
|
|
|
|
continue;
|
2005-04-12 01:55:38 +00:00
|
|
|
}
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
last = next;
|
|
|
|
}
|
2017-07-15 20:00:45 +00:00
|
|
|
MOVE_ARRAY(istate->cache, istate->cache + pos, last - pos);
|
2017-06-12 22:14:04 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
}
|
|
|
|
|
2017-05-11 22:04:25 +00: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;
|
|
|
|
}
|
|
|
|
|
2009-02-17 14:27:11 +00:00
|
|
|
static const char * const ls_files_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git ls-files [<options>] [<file>...]"),
|
2009-02-17 14:27:11 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static int option_parse_exclude(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
2013-01-16 13:25:58 +00:00
|
|
|
struct string_list *exclude_list = opt->value;
|
2009-02-17 14:27:11 +00:00
|
|
|
|
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 06:45:42 +00:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
2009-02-17 14:27:11 +00:00
|
|
|
exc_given = 1;
|
2013-01-16 13:25:58 +00:00
|
|
|
string_list_append(exclude_list, arg);
|
2009-02-17 14:27:11 +00:00
|
|
|
|
|
|
|
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 06:45:42 +00:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
2009-02-17 14:27:11 +00:00
|
|
|
exc_given = 1;
|
2019-09-03 18:04:57 +00:00
|
|
|
add_patterns_from_file(dir, arg);
|
2009-02-17 14:27:11 +00:00
|
|
|
|
|
|
|
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 06:45:42 +00:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
|
|
|
|
2009-02-17 14:27:11 +00:00
|
|
|
exc_given = 1;
|
|
|
|
setup_standard_excludes(dir);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2005-04-28 22:06:25 +00:00
|
|
|
|
2010-06-03 13:39:18 +00:00
|
|
|
int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
|
2005-04-12 01:55:38 +00:00
|
|
|
{
|
2013-01-16 13:25:58 +00:00
|
|
|
int require_work_tree = 0, show_tag = 0, i;
|
2021-04-25 14:16:10 +00:00
|
|
|
char *max_prefix;
|
2021-07-01 10:51:27 +00:00
|
|
|
struct dir_struct dir = DIR_INIT;
|
2019-09-03 18:04:56 +00:00
|
|
|
struct pattern_list *pl;
|
2013-01-16 13:25:58 +00:00
|
|
|
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
|
2009-02-17 14:27:11 +00:00
|
|
|
struct option builtin_ls_files_options[] = {
|
2016-01-31 11:35:46 +00:00
|
|
|
/* Think twice before adding "--nul" synonym to this */
|
|
|
|
OPT_SET_INT('z', NULL, &line_terminator,
|
2021-09-21 11:13:05 +00:00
|
|
|
N_("separate paths with the NUL character"), '\0'),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('t', NULL, &show_tag,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("identify the file status with tags")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('v', NULL, &show_valid_bit,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("use lowercase letters for 'assume unchanged' files")),
|
2017-09-22 16:35:42 +00:00
|
|
|
OPT_BOOL('f', NULL, &show_fsmonitor_bit,
|
|
|
|
N_("use lowercase letters for 'fsmonitor clean' files")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('c', "cached", &show_cached,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show cached files in the output (default)")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('d', "deleted", &show_deleted,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show deleted files in the output")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('m', "modified", &show_modified,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show modified files in the output")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('o', "others", &show_others,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show other files in the output")),
|
2009-02-17 14:27:11 +00:00
|
|
|
OPT_BIT('i', "ignored", &dir.flags,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show ignored files in the output"),
|
2009-02-17 14:27:11 +00:00
|
|
|
DIR_SHOW_IGNORED),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('s', "stage", &show_stage,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show staged contents' object name in the output")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('k', "killed", &show_killed,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show files on the filesystem that need to be removed")),
|
2009-02-17 14:27:11 +00:00
|
|
|
OPT_BIT(0, "directory", &dir.flags,
|
2014-08-30 19:56:01 +00:00
|
|
|
N_("show 'other' directories' names only"),
|
2009-02-17 14:27:11 +00:00
|
|
|
DIR_SHOW_OTHER_DIRECTORIES),
|
2016-01-16 06:50:02 +00:00
|
|
|
OPT_BOOL(0, "eol", &show_eol, N_("show line endings of files")),
|
2009-05-08 05:01:17 +00:00
|
|
|
OPT_NEGBIT(0, "empty-directory", &dir.flags,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("don't show empty directories"),
|
2009-02-17 14:27:11 +00:00
|
|
|
DIR_HIDE_EMPTY_DIRECTORIES),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('u', "unmerged", &show_unmerged,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show unmerged files in the output")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "resolve-undo", &show_resolve_undo,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("show resolve-undo information")),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
OPT_CALLBACK_F('x', "exclude", &exclude_list, N_("pattern"),
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("skip files matching pattern"),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
PARSE_OPT_NONEG, option_parse_exclude),
|
|
|
|
OPT_CALLBACK_F('X', "exclude-from", &dir, N_("file"),
|
2021-09-21 11:13:05 +00:00
|
|
|
N_("read exclude patterns from <file>"),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
PARSE_OPT_NONEG, option_parse_exclude_from),
|
2012-08-20 12:32:20 +00:00
|
|
|
OPT_STRING(0, "exclude-per-directory", &dir.exclude_per_dir, N_("file"),
|
|
|
|
N_("read additional per-directory exclude patterns in <file>")),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
OPT_CALLBACK_F(0, "exclude-standard", &dir, NULL,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("add the standard git exclusions"),
|
2018-11-05 06:39:20 +00:00
|
|
|
PARSE_OPT_NOARG | PARSE_OPT_NONEG,
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
option_parse_exclude_standard),
|
2018-05-20 15:42:58 +00:00
|
|
|
OPT_SET_INT_F(0, "full-name", &prefix_len,
|
|
|
|
N_("make the output relative to the project top directory"),
|
|
|
|
0, PARSE_OPT_NONEG),
|
2016-10-07 18:18:49 +00:00
|
|
|
OPT_BOOL(0, "recurse-submodules", &recurse_submodules,
|
|
|
|
N_("recurse through submodules")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "error-unmatch", &error_unmatch,
|
2012-08-20 12:32:20 +00:00
|
|
|
N_("if any <file> is not in the index, treat this as an error")),
|
|
|
|
OPT_STRING(0, "with-tree", &with_tree, N_("tree-ish"),
|
|
|
|
N_("pretend that paths removed since <tree-ish> are still present")),
|
2009-02-17 14:27:11 +00:00
|
|
|
OPT__ABBREV(&abbrev),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "debug", &debug_mode, N_("show debugging data")),
|
2021-01-23 10:20:10 +00:00
|
|
|
OPT_BOOL(0, "deduplicate", &skipping_duplicates,
|
|
|
|
N_("suppress duplicate entries")),
|
2021-12-22 14:20:53 +00:00
|
|
|
OPT_BOOL(0, "sparse", &show_sparse_dirs,
|
|
|
|
N_("show sparse directories in the presence of a sparse index")),
|
2022-07-23 06:44:45 +00:00
|
|
|
OPT_STRING_F(0, "format", &format, N_("format"),
|
|
|
|
N_("format to use for the output"),
|
|
|
|
PARSE_OPT_NONEG),
|
2009-02-17 14:27:11 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
2021-10-07 10:01:35 +00:00
|
|
|
int ret = 0;
|
2005-04-12 01:55:38 +00:00
|
|
|
|
2010-10-22 06:48:14 +00:00
|
|
|
if (argc == 2 && !strcmp(argv[1], "-h"))
|
|
|
|
usage_with_options(ls_files_usage, builtin_ls_files_options);
|
|
|
|
|
2021-12-22 14:20:53 +00:00
|
|
|
prepare_repo_settings(the_repository);
|
|
|
|
the_repository->settings.command_requires_full_index = 0;
|
|
|
|
|
2010-06-03 13:39:18 +00:00
|
|
|
prefix = cmd_prefix;
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
if (prefix)
|
2010-06-03 13:39:18 +00:00
|
|
|
prefix_len = strlen(prefix);
|
2008-05-14 17:46:53 +00:00
|
|
|
git_config(git_default_config, NULL);
|
[PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do
cd arch/i386
git-ls-files
and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).
The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).
The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.
For example, when doing
git-ls-files 'arch/i386/p*/*.c'
the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.
This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.
For example:
git-ls-files 'arch/i386/*.[ch]'
will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).
Also, while
git-ls-files arch/i386/
will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.
These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do
git-ls-files fs/*.c | xargs grep some_pattern
and it does what you want.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 19:55:33 +00:00
|
|
|
|
2017-06-22 18:43:48 +00:00
|
|
|
if (repo_read_index(the_repository) < 0)
|
2009-08-20 13:47:01 +00:00
|
|
|
die("index file corrupt");
|
|
|
|
|
2009-05-23 18:53:12 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
|
2009-02-17 14:27:11 +00:00
|
|
|
ls_files_usage, 0);
|
2019-09-03 18:04:57 +00:00
|
|
|
pl = add_pattern_list(&dir, EXC_CMDL, "--exclude option");
|
2013-01-16 13:25:58 +00:00
|
|
|
for (i = 0; i < exclude_list.nr; i++) {
|
2019-09-03 18:04:57 +00:00
|
|
|
add_pattern(exclude_list.items[i].string, "", 0, pl, --exclude_args);
|
2013-01-16 13:25:58 +00:00
|
|
|
}
|
2022-07-23 06:44:45 +00:00
|
|
|
|
|
|
|
if (format && (show_stage || show_others || show_killed ||
|
|
|
|
show_resolve_undo || skipping_duplicates || show_eol || show_tag))
|
|
|
|
usage_msg_opt(_("--format cannot be used with -s, -o, -k, -t, "
|
|
|
|
"--resolve-undo, --deduplicate, --eol"),
|
|
|
|
ls_files_usage, builtin_ls_files_options);
|
|
|
|
|
2017-09-22 16:35:42 +00:00
|
|
|
if (show_tag || show_valid_bit || show_fsmonitor_bit) {
|
2009-02-17 14:27:11 +00:00
|
|
|
tag_cached = "H ";
|
|
|
|
tag_unmerged = "M ";
|
|
|
|
tag_removed = "R ";
|
|
|
|
tag_modified = "C ";
|
|
|
|
tag_other = "? ";
|
|
|
|
tag_killed = "K ";
|
2009-08-20 13:46:57 +00:00
|
|
|
tag_skip_worktree = "S ";
|
2009-12-25 18:08:04 +00:00
|
|
|
tag_resolve_undo = "U ";
|
2005-04-28 18:44:04 +00:00
|
|
|
}
|
2009-03-20 21:30:51 +00:00
|
|
|
if (show_modified || show_others || show_deleted || (dir.flags & DIR_SHOW_IGNORED) || show_killed)
|
2009-02-17 14:27:11 +00:00
|
|
|
require_work_tree = 1;
|
|
|
|
if (show_unmerged)
|
|
|
|
/*
|
|
|
|
* There's no point in showing unmerged unless
|
|
|
|
* you also show the stage information.
|
|
|
|
*/
|
|
|
|
show_stage = 1;
|
2021-01-23 10:20:10 +00:00
|
|
|
if (show_tag || show_stage)
|
|
|
|
skipping_duplicates = 0;
|
2009-02-17 14:27:11 +00:00
|
|
|
if (dir.exclude_per_dir)
|
|
|
|
exc_given = 1;
|
2005-04-28 18:44:04 +00:00
|
|
|
|
2007-11-03 11:23:12 +00:00
|
|
|
if (require_work_tree && !is_inside_work_tree())
|
|
|
|
setup_work_tree();
|
2007-01-23 12:30:20 +00:00
|
|
|
|
2016-10-07 18:18:49 +00:00
|
|
|
if (recurse_submodules &&
|
2022-02-24 00:23:03 +00:00
|
|
|
(show_deleted || show_others || show_unmerged ||
|
2016-10-07 18:18:50 +00:00
|
|
|
show_killed || show_modified || show_resolve_undo || with_tree))
|
2016-10-07 18:18:49 +00:00
|
|
|
die("ls-files --recurse-submodules unsupported mode");
|
|
|
|
|
|
|
|
if (recurse_submodules && error_unmatch)
|
|
|
|
die("ls-files --recurse-submodules does not support "
|
|
|
|
"--error-unmatch");
|
|
|
|
|
2013-07-14 08:35:43 +00:00
|
|
|
parse_pathspec(&pathspec, 0,
|
2017-05-11 22:04:25 +00:00
|
|
|
PATHSPEC_PREFER_CWD,
|
2013-07-14 08:35:43 +00:00
|
|
|
prefix, argv);
|
2009-02-07 13:43:03 +00:00
|
|
|
|
2016-10-07 18:18:51 +00:00
|
|
|
/*
|
|
|
|
* Find common prefix for all pathspec's
|
|
|
|
* This is used as a performance optimization which unfortunately cannot
|
2017-06-22 18:43:48 +00:00
|
|
|
* 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.
|
2016-10-07 18:18:51 +00:00
|
|
|
*/
|
|
|
|
if (recurse_submodules)
|
|
|
|
max_prefix = NULL;
|
|
|
|
else
|
|
|
|
max_prefix = common_prefix(&pathspec);
|
2017-05-11 22:04:25 +00:00
|
|
|
max_prefix_len = get_common_prefix_len(max_prefix);
|
|
|
|
|
2017-06-22 18:43:48 +00:00
|
|
|
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-21 19:55:33 +00:00
|
|
|
|
2006-02-14 20:40:20 +00:00
|
|
|
/* Treat unmatching pathspec elements as errors */
|
2013-07-14 08:35:43 +00:00
|
|
|
if (pathspec.nr && error_unmatch)
|
2015-08-20 16:57:32 +00:00
|
|
|
ps_matched = xcalloc(pathspec.nr, 1);
|
2006-02-14 20:40:20 +00:00
|
|
|
|
ls-files: error out on -i unless -o or -c are specified
ls-files --ignored can be used together with either --others or
--cached. After being perplexed for a bit and digging in to the code, I
assumed that ls-files -i was just broken and not printing anything and
I had a nice patch ready to submit when I finally realized that -i can be
used with --cached to find tracked ignores.
While that was a mistake on my part, and a careful reading of the
documentation could have made this more clear, I suspect this is an
error others are likely to make as well. In fact, of two uses in our
testsuite, I believe one of the two did make this error. In t1306.13,
there are NO tracked files, and all the excludes built up and used in
that test and in previous tests thus have to be about untracked files.
However, since they were looking for an empty result, the mistake went
unnoticed as their erroneous command also just happened to give an empty
answer.
-i will most the time be used with -o, which would suggest we could just
make -i imply -o in the absence of either a -o or -c, but that would be
a backward incompatible break. Instead, let's just flag -i without
either a -o or -c as an error, and update the two relevant testcases to
specify their intent.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-12 17:28:16 +00:00
|
|
|
if ((dir.flags & DIR_SHOW_IGNORED) && !show_others && !show_cached)
|
|
|
|
die("ls-files -i must be used with either -o or -c");
|
|
|
|
|
2009-10-09 01:53:35 +00:00
|
|
|
if ((dir.flags & DIR_SHOW_IGNORED) && !exc_given)
|
|
|
|
die("ls-files --ignored needs some exclude pattern");
|
2005-04-12 01:55:38 +00:00
|
|
|
|
|
|
|
/* With no flags, we default to showing the cached files */
|
2013-06-13 18:19:44 +00:00
|
|
|
if (!(show_stage || show_deleted || show_others || show_unmerged ||
|
|
|
|
show_killed || show_modified || show_resolve_undo))
|
2005-04-12 01:55:38 +00:00
|
|
|
show_cached = 1;
|
|
|
|
|
2007-09-12 23:04:22 +00:00
|
|
|
if (with_tree) {
|
|
|
|
/*
|
|
|
|
* Basic sanity check; show-stages and show-unmerged
|
|
|
|
* would not make any sense with this option.
|
|
|
|
*/
|
|
|
|
if (show_stage || show_unmerged)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "ls-files --with-tree", "-s/-u");
|
2017-06-22 18:43:48 +00:00
|
|
|
overlay_tree_on_index(the_repository->index, with_tree, max_prefix);
|
2007-09-12 23:04:22 +00:00
|
|
|
}
|
2017-06-22 18:43:48 +00:00
|
|
|
|
|
|
|
show_files(the_repository, &dir);
|
|
|
|
|
2009-12-25 18:08:04 +00:00
|
|
|
if (show_resolve_undo)
|
2017-06-22 18:43:48 +00:00
|
|
|
show_ru_info(the_repository->index);
|
2006-02-14 20:40:20 +00:00
|
|
|
|
2021-10-07 10:01:35 +00:00
|
|
|
if (ps_matched && report_path_error(ps_matched, &pathspec)) {
|
|
|
|
fprintf(stderr, "Did you forget to 'git add'?\n");
|
|
|
|
ret = 1;
|
2006-02-14 20:40:20 +00:00
|
|
|
}
|
|
|
|
|
2021-10-07 10:01:36 +00:00
|
|
|
string_list_clear(&exclude_list, 0);
|
dir: fix problematic API to avoid memory leaks
The dir structure seemed to have a number of leaks and problems around
it. First I noticed that parent_hashmap and recursive_hashmap were
being leaked (though Peff noticed and submitted fixes before me). Then
I noticed in the previous commit that clear_directory() was only taking
responsibility for a subset of fields within dir_struct, despite the
fact that entries[] and ignored[] we allocated internally to dir.c.
That, of course, resulted in many callers either leaking or haphazardly
trying to free these arrays and their contents.
Digging further, I found that despite the pretty clear documentation
near the top of dir.h that folks were supposed to call clear_directory()
when the user no longer needed the dir_struct, there were four callers
that didn't bother doing that at all. However, two of them clearly
thought about leaks since they had an UNLEAK(dir) directive, which to me
suggests that the method to free the data was too unclear. I suspect
the non-obviousness of the API and its holes led folks to avoid it,
which then snowballed into further problems with the entries[],
ignored[], parent_hashmap, and recursive_hashmap problems.
Rename clear_directory() to dir_clear() to be more in line with other
data structures in git, and introduce a dir_init() to handle the
suggested memsetting of dir_struct to all zeroes. I hope that a name
like "dir_clear()" is more clear, and that the presence of dir_init()
will provide a hint to those looking at the code that they need to look
for either a dir_clear() or a dir_free() and lead them to find
dir_clear().
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18 22:58:26 +00:00
|
|
|
dir_clear(&dir);
|
2021-04-25 14:16:10 +00:00
|
|
|
free(max_prefix);
|
2021-10-07 10:01:35 +00:00
|
|
|
return ret;
|
2005-04-12 01:55:38 +00:00
|
|
|
}
|