git/builtin/ls-tree.c

187 строки
4.8 KiB
C
Исходник Обычный вид История

/*
* GIT - The information manager from hell
*
* Copyright (C) Linus Torvalds, 2005
*/
#include "cache.h"
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
#include "blob.h"
#include "tree.h"
#include "commit.h"
#include "quote.h"
#include "builtin.h"
#include "parse-options.h"
#include "pathspec.h"
static int line_termination = '\n';
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
#define LS_RECURSIVE 1
#define LS_TREE_ONLY 2
#define LS_SHOW_TREES 4
#define LS_NAME_ONLY 8
#define LS_SHOW_SIZE 16
static int abbrev;
static int ls_options;
static struct pathspec pathspec;
static int chomp_prefix;
static const char *ls_tree_prefix;
static const char * const ls_tree_usage[] = {
N_("git ls-tree [<options>] <tree-ish> [<path>...]"),
NULL
};
static int show_recursive(const char *base, int baselen, const char *pathname)
{
const char **s;
if (ls_options & LS_RECURSIVE)
return 1;
s = pathspec._raw;
if (!s)
return 0;
for (;;) {
const char *spec = *s++;
int len, speclen;
if (!spec)
return 0;
if (strncmp(base, spec, baselen))
continue;
len = strlen(pathname);
spec += baselen;
speclen = strlen(spec);
if (speclen <= len)
continue;
if (spec[len] && spec[len] != '/')
continue;
if (memcmp(pathname, spec, len))
continue;
return 1;
}
}
static int show_tree(const unsigned char *sha1, const char *base, int baselen,
const char *pathname, unsigned mode, int stage, void *context)
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
{
int retval = 0;
const char *type = blob_type;
if (S_ISGITLINK(mode)) {
/*
* Maybe we want to have some recursive version here?
*
* Something similar to this incomplete example:
*
if (show_subprojects(base, baselen, pathname))
retval = READ_TREE_RECURSIVE;
*
*/
type = commit_type;
} else if (S_ISDIR(mode)) {
if (show_recursive(base, baselen, pathname)) {
retval = READ_TREE_RECURSIVE;
if (!(ls_options & LS_SHOW_TREES))
return retval;
ls-tree: further tweaks of the rewrite It modifies the selection a bit, so that a pathspec that is a superset of a particular tree path will always cause it to recurse into that tree. As an example, let's say that we do git-ls-tree HEAD drivers/char _without_ the "-r". What will happen is that it will start out doing all the base tree, and for "drivers" it will notice that it's a proper subset of "drivers/char", so it will always recurse into _that_ tree (but not into other trees). Then, it will not match anything else than "char" in that subdirectory, and because that's not a proper superset (it's an exact match), it will _not_ recurse into it, so you get: [torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char 040000 tree 9568cda453aae205bb58983747fa73b9696d9d51 drivers/char which is what you got with the old git-ls-tree too. But interestingly, if you add the slash, it will become a proper superset and it will recurse into _that_ subdirectory (but no deeper: so if you want all subdirectories _below_ drivers/char/, you still need to give "-r"): [torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char/ 100644 blob 2b6b1d772ed776fff87927fc34adc2e40500218e drivers/char/.gitignore 100644 blob 56b8a2e76ab10a5c21787cb7068a846075cbaffd drivers/char/ChangeLog 100644 blob 970f70d498f4c814e1cf3362e33d7e23ac53c299 drivers/char/Kconfig ... See? This is on top of the previous two diffs, holler if you want a whole new "everything combined" version.. It hasn't gotten lots of testing, but it should work. Linus
2005-11-28 09:48:08 +03:00
}
type = tree_type;
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
}
else if (ls_options & LS_TREE_ONLY)
return 0;
ls-tree: chomp leading directories when run from a subdirectory When run from a subdirectory, even though we filtered the output based on where we were using pathspec, we wrote out the repository relative paths, not subtree relative paths. This changes things so that it shows only the current subdirectory relative paths. For example, in Documentation subdirectory of git itself, this used to be the case: $ git-ls-tree --name-only HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto But now it does this instead: $ git-ls-tree --name-only HEAD | grep how git-show-branch.txt git-show-index.txt howto-index.sh howto There are two things to keep in mind. 1. This shows nothing. $ git-ls-tree --name-only HEAD ../ppc/ This is to make things consistent with ls-files, which refuses relative path that goes uplevel. 2. These show things in full repository relative paths. In this case, paths outside the current subdirectory are also shown. $ git-ls-tree --name-only --full-name HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto $ git-ls-tree --name-only --full-name HEAD ../ppc/ ppc/sha1.c ppc/sha1.h ppc/sha1ppc.S The flag --full-name gives the same behaviour as 1.0, so it ought to be the default if we really care about the backward compatibility, but in practice no Porcelain runs ls-tree from a subdirectory yet, and without --full-name is more human friendly, so hopefully the default being not --full-name would be acceptable. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-24 00:39:30 +03:00
if (chomp_prefix &&
(baselen < chomp_prefix || memcmp(ls_tree_prefix, base, chomp_prefix)))
ls-tree: chomp leading directories when run from a subdirectory When run from a subdirectory, even though we filtered the output based on where we were using pathspec, we wrote out the repository relative paths, not subtree relative paths. This changes things so that it shows only the current subdirectory relative paths. For example, in Documentation subdirectory of git itself, this used to be the case: $ git-ls-tree --name-only HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto But now it does this instead: $ git-ls-tree --name-only HEAD | grep how git-show-branch.txt git-show-index.txt howto-index.sh howto There are two things to keep in mind. 1. This shows nothing. $ git-ls-tree --name-only HEAD ../ppc/ This is to make things consistent with ls-files, which refuses relative path that goes uplevel. 2. These show things in full repository relative paths. In this case, paths outside the current subdirectory are also shown. $ git-ls-tree --name-only --full-name HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto $ git-ls-tree --name-only --full-name HEAD ../ppc/ ppc/sha1.c ppc/sha1.h ppc/sha1ppc.S The flag --full-name gives the same behaviour as 1.0, so it ought to be the default if we really care about the backward compatibility, but in practice no Porcelain runs ls-tree from a subdirectory yet, and without --full-name is more human friendly, so hopefully the default being not --full-name would be acceptable. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-24 00:39:30 +03:00
return 0;
if (!(ls_options & LS_NAME_ONLY)) {
if (ls_options & LS_SHOW_SIZE) {
char size_text[24];
if (!strcmp(type, blob_type)) {
unsigned long size;
if (sha1_object_info(sha1, &size) == OBJ_BAD)
strcpy(size_text, "BAD");
else
snprintf(size_text, sizeof(size_text),
"%lu", size);
} else
strcpy(size_text, "-");
printf("%06o %s %s %7s\t", mode, type,
find_unique_abbrev(sha1, abbrev),
size_text);
} else
printf("%06o %s %s\t", mode, type,
find_unique_abbrev(sha1, abbrev));
}
write_name_quotedpfx(base + chomp_prefix, baselen - chomp_prefix,
pathname, stdout, line_termination);
return retval;
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
}
int cmd_ls_tree(int argc, const char **argv, const char *prefix)
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
{
unsigned char sha1[20];
struct tree *tree;
int i, full_tree = 0;
const struct option ls_tree_options[] = {
OPT_BIT('d', NULL, &ls_options, N_("only show trees"),
LS_TREE_ONLY),
OPT_BIT('r', NULL, &ls_options, N_("recurse into subtrees"),
LS_RECURSIVE),
OPT_BIT('t', NULL, &ls_options, N_("show trees when recursing"),
LS_SHOW_TREES),
OPT_SET_INT('z', NULL, &line_termination,
N_("terminate entries with NUL byte"), 0),
OPT_BIT('l', "long", &ls_options, N_("include object size"),
LS_SHOW_SIZE),
OPT_BIT(0, "name-only", &ls_options, N_("list only filenames"),
LS_NAME_ONLY),
OPT_BIT(0, "name-status", &ls_options, N_("list only filenames"),
LS_NAME_ONLY),
OPT_SET_INT(0, "full-name", &chomp_prefix,
N_("use full path names"), 0),
OPT_BOOL(0, "full-tree", &full_tree,
N_("list entire tree; not just current directory "
"(implies --full-name)")),
OPT__ABBREV(&abbrev),
OPT_END()
};
git_config(git_default_config, NULL);
ls_tree_prefix = prefix;
ls-tree: chomp leading directories when run from a subdirectory When run from a subdirectory, even though we filtered the output based on where we were using pathspec, we wrote out the repository relative paths, not subtree relative paths. This changes things so that it shows only the current subdirectory relative paths. For example, in Documentation subdirectory of git itself, this used to be the case: $ git-ls-tree --name-only HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto But now it does this instead: $ git-ls-tree --name-only HEAD | grep how git-show-branch.txt git-show-index.txt howto-index.sh howto There are two things to keep in mind. 1. This shows nothing. $ git-ls-tree --name-only HEAD ../ppc/ This is to make things consistent with ls-files, which refuses relative path that goes uplevel. 2. These show things in full repository relative paths. In this case, paths outside the current subdirectory are also shown. $ git-ls-tree --name-only --full-name HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto $ git-ls-tree --name-only --full-name HEAD ../ppc/ ppc/sha1.c ppc/sha1.h ppc/sha1ppc.S The flag --full-name gives the same behaviour as 1.0, so it ought to be the default if we really care about the backward compatibility, but in practice no Porcelain runs ls-tree from a subdirectory yet, and without --full-name is more human friendly, so hopefully the default being not --full-name would be acceptable. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-24 00:39:30 +03:00
if (prefix && *prefix)
chomp_prefix = strlen(prefix);
argc = parse_options(argc, argv, prefix, ls_tree_options,
ls_tree_usage, 0);
if (full_tree) {
ls_tree_prefix = prefix = NULL;
chomp_prefix = 0;
}
/* -d -r should imply -t, but -d by itself should not have to. */
if ( (LS_TREE_ONLY|LS_RECURSIVE) ==
((LS_TREE_ONLY|LS_RECURSIVE) & ls_options))
ls_options |= LS_SHOW_TREES;
if (argc < 1)
usage_with_options(ls_tree_usage, ls_tree_options);
if (get_sha1(argv[0], sha1))
die("Not a valid object name %s", argv[0]);
[PATCH] Rewrite ls-tree to behave more like "/bin/ls -a" This is a complete rewrite of ls-tree to make it behave more like what "/bin/ls -a" does in the current working directory. Namely, the changes are: - Unlike the old ls-tree behaviour that used paths arguments to restrict output (not that it worked as intended---as pointed out in the mailing list discussion, it was quite incoherent), this rewrite uses paths arguments to specify what to show. - Without arguments, it implicitly uses the root level as its sole argument ("/bin/ls -a" behaves as if "." is given without argument). - Without -r (recursive) flag, it shows the named blob (either file or symlink), or the named tree and its immediate children. - With -r flag, it shows the named path, and recursively descends into it if it is a tree. - With -d flag, it shows the named path and does not show its children even if the path is a tree, nor descends into it recursively. This is still request-for-comments patch. There is no mailing list consensus that this proposed new behaviour is a good one. The patch to t/t3100-ls-tree-restrict.sh illustrates user-visible behaviour changes. Namely: * "git-ls-tree $tree path1 path0" lists path1 first and then path0. It used to use paths as an output restrictor and showed output in cache entry order (i.e. path0 first and then path1) regardless of the order of paths arguments. * "git-ls-tree $tree path2" lists path2 and its immediate children but having explicit paths argument does not imply recursive behaviour anymore, hence paths/baz is shown but not paths/baz/b. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 11:05:38 +04:00
/*
* show_recursive() rolls its own matching code and is
* generally ignorant of 'struct pathspec'. The magic mask
* cannot be lifted until it is converted to use
* match_pathspec_depth() or tree_entry_interesting()
*/
parse_pathspec(&pathspec, PATHSPEC_GLOB | PATHSPEC_ICASE,
PATHSPEC_PREFER_CWD,
prefix, argv + 1);
for (i = 0; i < pathspec.nr; i++)
pathspec.items[i].nowildcard_len = pathspec.items[i].len;
pathspec.has_wildcard = 0;
tree = parse_tree_indirect(sha1);
if (!tree)
die("not a tree object");
return !!read_tree_recursive(tree, "", 0, 0, &pathspec, show_tree, NULL);
}