mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 08:47:56 +01:00
Code Activity
git/ls-tree.c

156 lines
3.4 KiB
C
Raw Normal View History

[PATCH] ls-tree for listing trees ls-tree tool provides just a way to export the binary tree objects to a usable text format. This is bound to be useful in variety of scripts, although none of those I have currently uses it. But e.g. the simple script I've sent to HPA for purging the object database uses it. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-13 11:02:34 +02:00
/*
* 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 09:05:38 +02:00
#include "blob.h"
#include "tree.h"
Update ls-files and ls-tree to use C-style quoting for funny pathnames. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15 06:56:46 +02:00
#include "quote.h"
[PATCH] ls-tree for listing trees ls-tree tool provides just a way to export the binary tree objects to a usable text format. This is bound to be useful in variety of scripts, although none of those I have currently uses it. But e.g. the simple script I've sent to HPA for purging the object database uses it. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-13 11:02:34 +02:00
sparse cleanup Fix various things that sparse complains about: - use NULL instead of 0 - make sure we declare everything properly, or mark it static - use proper function declarations ("fn(void)" instead of "fn()") Sparse is always right.
2005-05-20 20:46:10 +02:00
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 09:05:38 +02:00
#define LS_RECURSIVE 1
#define LS_TREE_ONLY 2
git-ls-tree: add "-t" option to always show the tree entries The old (new) behaviour was that it only shows trees if the object is specified exactly, and recursive is not set. That makes sense, because there is obviously nothing else it can show for that case. However, with the new "-t" option, it will show the tree even with "-r", as it traverses down into it. NOTE! This also means that it will show all trees leading up to that tree. For example, if you do a git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist it will show the trees that lead up to the files that do not exist: [torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist 040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers 040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char [torvalds@g5 linux]$ and note how this is true even though I didn't specify "-r": the fact that I supplied a pathspec automatically implies "enough recursion" for that particular pathspec. I think the code is cleaner and easier to understand too: the patch looks bigger, but it's really just splitting up the "should we recurse into this tree" into a function of its own. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 19:35:51 +01:00
#define LS_SHOW_TREES 4
ls-tree: --name-only Fingers of some "git diff" users are trained to do --name-only which git-ls-tree unfortunately does not take. With this, cd sub/directory && git-ls-tree -r --name-only .. would show only the names not object names nor modes. I threw in another synonym --name-status only for usability, but obviously ls-tree does not do any comparison so what it does is the same as --name-only. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 23:54:00 +01:00
#define LS_NAME_ONLY 8
ls-tree: add --abbrev[=<n>] option Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-07 14:52:02 +01:00
static int abbrev = 0;
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 07:48:08 +01:00
static int ls_options = 0;
const char **pathspec;
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-23 22:39:30 +01:00
static int chomp_prefix = 0;
static const char *prefix;
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
ls-tree: major rewrite to do pathspec git-ls-tree should be rewritten to use a pathspec the same way everybody else does. Right now it's the odd man out: if you do git-ls-tree HEAD divers/char drivers/ it will show the same files _twice_, which is not how pathspecs in general work. How about this patch? It breaks some of the git-ls-tree tests, but it makes git-ls-tree work a lot more like other git pathspec commands, and it removes more than 150 lines by re-using the recursive tree traversal (but the "-d" flag is gone for good, so I'm not pushing this too hard). Linus
2005-11-26 18:38:20 +01:00
static const char ls_tree_usage[] =
ls-tree: add --abbrev[=<n>] option Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-07 14:52:02 +01:00
"git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]";
git-ls-tree: add "-t" option to always show the tree entries The old (new) behaviour was that it only shows trees if the object is specified exactly, and recursive is not set. That makes sense, because there is obviously nothing else it can show for that case. However, with the new "-t" option, it will show the tree even with "-r", as it traverses down into it. NOTE! This also means that it will show all trees leading up to that tree. For example, if you do a git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist it will show the trees that lead up to the files that do not exist: [torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist 040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers 040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char [torvalds@g5 linux]$ and note how this is true even though I didn't specify "-r": the fact that I supplied a pathspec automatically implies "enough recursion" for that particular pathspec. I think the code is cleaner and easier to understand too: the patch looks bigger, but it's really just splitting up the "should we recurse into this tree" into a function of its own. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 19:35:51 +01:00
static int show_recursive(const char *base, int baselen, const char *pathname)
{
const char **s;
if (ls_options & LS_RECURSIVE)
return 1;
s = pathspec;
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 (memcmp(pathname, spec, len))
continue;
return 1;
}
}
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
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-23 22:39:30 +01:00
static int show_tree(unsigned char *sha1, const char *base, int baselen,
const char *pathname, unsigned mode, int stage)
[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 09:05:38 +02:00
{
git-ls-tree: add "-t" option to always show the tree entries The old (new) behaviour was that it only shows trees if the object is specified exactly, and recursive is not set. That makes sense, because there is obviously nothing else it can show for that case. However, with the new "-t" option, it will show the tree even with "-r", as it traverses down into it. NOTE! This also means that it will show all trees leading up to that tree. For example, if you do a git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist it will show the trees that lead up to the files that do not exist: [torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist 040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers 040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char [torvalds@g5 linux]$ and note how this is true even though I didn't specify "-r": the fact that I supplied a pathspec automatically implies "enough recursion" for that particular pathspec. I think the code is cleaner and easier to understand too: the patch looks bigger, but it's really just splitting up the "should we recurse into this tree" into a function of its own. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 19:35:51 +01:00
int retval = 0;
Use blob_, commit_, tag_, and tree_type throughout. This replaces occurences of "blob", "commit", "tag", and "tree", where they're really used as type specifiers, which we already have defined global constants for. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-02 14:44:09 +02:00
const char *type = blob_type;
Fix wrong filename listing bug in git-ls-tree. This patch fixes a bug in git-ls-tree in which the wrong filenames are listed if the exact same file and directory contents are present in another location in the tree. Added a new series of test cases for directory and filename handling. Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-08 01:54:06 +02:00
ls-tree: major rewrite to do pathspec git-ls-tree should be rewritten to use a pathspec the same way everybody else does. Right now it's the odd man out: if you do git-ls-tree HEAD divers/char drivers/ it will show the same files _twice_, which is not how pathspecs in general work. How about this patch? It breaks some of the git-ls-tree tests, but it makes git-ls-tree work a lot more like other git pathspec commands, and it removes more than 150 lines by re-using the recursive tree traversal (but the "-d" flag is gone for good, so I'm not pushing this too hard). Linus
2005-11-26 18:38:20 +01:00
if (S_ISDIR(mode)) {
git-ls-tree: add "-t" option to always show the tree entries The old (new) behaviour was that it only shows trees if the object is specified exactly, and recursive is not set. That makes sense, because there is obviously nothing else it can show for that case. However, with the new "-t" option, it will show the tree even with "-r", as it traverses down into it. NOTE! This also means that it will show all trees leading up to that tree. For example, if you do a git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist it will show the trees that lead up to the files that do not exist: [torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist 040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers 040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char [torvalds@g5 linux]$ and note how this is true even though I didn't specify "-r": the fact that I supplied a pathspec automatically implies "enough recursion" for that particular pathspec. I think the code is cleaner and easier to understand too: the patch looks bigger, but it's really just splitting up the "should we recurse into this tree" into a function of its own. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 19:35:51 +01:00
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 07:48:08 +01:00
}
Use blob_, commit_, tag_, and tree_type throughout. This replaces occurences of "blob", "commit", "tag", and "tree", where they're really used as type specifiers, which we already have defined global constants for. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-02 14:44:09 +02: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 09:05:38 +02:00
}
ls-tree: resurrect '-d' to mean 'show trees only' With this: git-ls-tree -d HEAD -- drivers/net/ shows only immediate subtrees of drivers/net. git-ls-tree -d -t HEAD -- drivers/net/ shows drivers, drivers/net and immediate subtrees of drivers/net. git-ls-tree -d -r HEAD -- drivers/net/ shows drivers, drivers/net and all subtrees of drivers/net (but not blobs). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 22:15:20 +01:00
else if (ls_options & LS_TREE_ONLY)
return 0;
Fix wrong filename listing bug in git-ls-tree. This patch fixes a bug in git-ls-tree in which the wrong filenames are listed if the exact same file and directory contents are present in another location in the tree. Added a new series of test cases for directory and filename handling. Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-08 01:54:06 +02:00
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-23 22:39:30 +01:00
if (chomp_prefix &&
(baselen < chomp_prefix || memcmp(prefix, base, chomp_prefix)))
return 0;
ls-tree: --name-only Fingers of some "git diff" users are trained to do --name-only which git-ls-tree unfortunately does not take. With this, cd sub/directory && git-ls-tree -r --name-only .. would show only the names not object names nor modes. I threw in another synonym --name-status only for usability, but obviously ls-tree does not do any comparison so what it does is the same as --name-only. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 23:54:00 +01:00
if (!(ls_options & LS_NAME_ONLY))
ls-tree: add --abbrev[=<n>] option Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-07 14:52:02 +01:00
printf("%06o %s %s\t", mode, type,
abbrev ? find_unique_abbrev(sha1,abbrev)
: sha1_to_hex(sha1));
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-23 22:39:30 +01:00
write_name_quoted(base + chomp_prefix, baselen - chomp_prefix,
pathname,
line_termination, stdout);
ls-tree: Resurrect funny name quoting lost during rewrite. The rewrite to match ls-files/diff-tree behaviour accidentally lost the name quoting. I am not proud about this code, but this would get the test going. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-28 11:30:04 +01:00
putchar(line_termination);
git-ls-tree: add "-t" option to always show the tree entries The old (new) behaviour was that it only shows trees if the object is specified exactly, and recursive is not set. That makes sense, because there is obviously nothing else it can show for that case. However, with the new "-t" option, it will show the tree even with "-r", as it traverses down into it. NOTE! This also means that it will show all trees leading up to that tree. For example, if you do a git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist it will show the trees that lead up to the files that do not exist: [torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist 040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers 040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char [torvalds@g5 linux]$ and note how this is true even though I didn't specify "-r": the fact that I supplied a pathspec automatically implies "enough recursion" for that particular pathspec. I think the code is cleaner and easier to understand too: the patch looks bigger, but it's really just splitting up the "should we recurse into this tree" into a function of its own. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 19:35:51 +01:00
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 09:05:38 +02:00
}
[PATCH] Un unoptimize ls-tree behaviour ls-tree unconditionally called read_sha1_file() for all paths even when not needed, which was a mistake introduced by me. Rectify this by first checking S_ISDIR(mode) and read the tree contents only when it is a tree and we are recursive. There is no need to read it in any other cases. The patch also removes the confusing comment that led to this incorrect implementation. Thanks to Peter Baudis for noticing this problem. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 22:57:39 +02:00
ls-tree: major rewrite to do pathspec git-ls-tree should be rewritten to use a pathspec the same way everybody else does. Right now it's the odd man out: if you do git-ls-tree HEAD divers/char drivers/ it will show the same files _twice_, which is not how pathspecs in general work. How about this patch? It breaks some of the git-ls-tree tests, but it makes git-ls-tree work a lot more like other git pathspec commands, and it removes more than 150 lines by re-using the recursive tree traversal (but the "-d" flag is gone for good, so I'm not pushing this too hard). Linus
2005-11-26 18:38:20 +01:00
int main(int argc, const char **argv)
[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 09:05:38 +02:00
{
[PATCH] ls-tree for listing trees ls-tree tool provides just a way to export the binary tree objects to a usable text format. This is bound to be useful in variety of scripts, although none of those I have currently uses it. But e.g. the simple script I've sent to HPA for purging the object database uses it. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-13 11:02:34 +02:00
unsigned char sha1[20];
Only use a single parser for tree objects This makes read_tree_recursive and read_tree take a struct tree instead of a buffer. It also move the declaration of read_tree into tree.h (where struct tree is defined), and updates ls-tree and diff-index (the only places that presently use read_tree*()) to use the new versions. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26 07:13:36 +01:00
struct tree *tree;
[PATCH] ls-tree for listing trees ls-tree tool provides just a way to export the binary tree objects to a usable text format. This is bound to be useful in variety of scripts, although none of those I have currently uses it. But e.g. the simple script I've sent to HPA for purging the object database uses it. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-13 11:02:34 +02:00
ls-tree: major rewrite to do pathspec git-ls-tree should be rewritten to use a pathspec the same way everybody else does. Right now it's the odd man out: if you do git-ls-tree HEAD divers/char drivers/ it will show the same files _twice_, which is not how pathspecs in general work. How about this patch? It breaks some of the git-ls-tree tests, but it makes git-ls-tree work a lot more like other git pathspec commands, and it removes more than 150 lines by re-using the recursive tree traversal (but the "-d" flag is gone for good, so I'm not pushing this too hard). Linus
2005-11-26 18:38:20 +01:00
prefix = setup_git_directory();
sha1_name: warning ambiguous refs. This makes sure that many commands that take refs on the command line to honor core.warnambiguousrefs configuration. Earlier, the commands affected by this patch did not read the configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-24 08:41:18 +01:00
git_config(git_default_config);
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-23 22:39:30 +01:00
if (prefix && *prefix)
chomp_prefix = strlen(prefix);
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
while (1 < argc && argv[1][0] == '-') {
switch (argv[1][1]) {
case 'z':
line_termination = 0;
break;
case 'r':
[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 09:05:38 +02:00
ls_options |= LS_RECURSIVE;
break;
case 'd':
ls_options |= LS_TREE_ONLY;
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
break;
git-ls-tree: add "-t" option to always show the tree entries The old (new) behaviour was that it only shows trees if the object is specified exactly, and recursive is not set. That makes sense, because there is obviously nothing else it can show for that case. However, with the new "-t" option, it will show the tree even with "-r", as it traverses down into it. NOTE! This also means that it will show all trees leading up to that tree. For example, if you do a git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist it will show the trees that lead up to the files that do not exist: [torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist 040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266 drivers 040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66 drivers/char [torvalds@g5 linux]$ and note how this is true even though I didn't specify "-r": the fact that I supplied a pathspec automatically implies "enough recursion" for that particular pathspec. I think the code is cleaner and easier to understand too: the patch looks bigger, but it's really just splitting up the "should we recurse into this tree" into a function of its own. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 19:35:51 +01:00
case 't':
ls_options |= LS_SHOW_TREES;
break;
ls-tree: --name-only Fingers of some "git diff" users are trained to do --name-only which git-ls-tree unfortunately does not take. With this, cd sub/directory && git-ls-tree -r --name-only .. would show only the names not object names nor modes. I threw in another synonym --name-status only for usability, but obviously ls-tree does not do any comparison so what it does is the same as --name-only. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 23:54:00 +01:00
case '-':
if (!strcmp(argv[1]+2, "name-only") ||
!strcmp(argv[1]+2, "name-status")) {
ls_options |= LS_NAME_ONLY;
break;
}
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-23 22:39:30 +01:00
if (!strcmp(argv[1]+2, "full-name")) {
chomp_prefix = 0;
break;
}
ls-tree: add --abbrev[=<n>] option Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-07 14:52:02 +01:00
if (!strncmp(argv[1]+2, "abbrev=",7)) {
abbrev = strtoul(argv[1]+9, NULL, 10);
if (abbrev && abbrev < MINIMUM_ABBREV)
abbrev = MINIMUM_ABBREV;
else if (abbrev > 40)
abbrev = 40;
break;
}
if (!strcmp(argv[1]+2, "abbrev")) {
abbrev = DEFAULT_ABBREV;
break;
}
ls-tree: --name-only Fingers of some "git diff" users are trained to do --name-only which git-ls-tree unfortunately does not take. With this, cd sub/directory && git-ls-tree -r --name-only .. would show only the names not object names nor modes. I threw in another synonym --name-status only for usability, but obviously ls-tree does not do any comparison so what it does is the same as --name-only. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 23:54:00 +01:00
/* otherwise fallthru */
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
default:
[PATCH] Un unoptimize ls-tree behaviour ls-tree unconditionally called read_sha1_file() for all paths even when not needed, which was a mistake introduced by me. Rectify this by first checking S_ISDIR(mode) and read the tree contents only when it is a tree and we are recursive. There is no need to read it in any other cases. The patch also removes the confusing comment that led to this incorrect implementation. Thanks to Peter Baudis for noticing this problem. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 22:57:39 +02:00
usage(ls_tree_usage);
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
}
argc--; argv++;
}
ls-tree: resurrect '-d' to mean 'show trees only' With this: git-ls-tree -d HEAD -- drivers/net/ shows only immediate subtrees of drivers/net. git-ls-tree -d -t HEAD -- drivers/net/ shows drivers, drivers/net and immediate subtrees of drivers/net. git-ls-tree -d -r HEAD -- drivers/net/ shows drivers, drivers/net and all subtrees of drivers/net (but not blobs). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 22:15:20 +01:00
/* -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;
[PATCH] ls-tree enhancements This adds '-r' (recursive) option and '-z' (NUL terminated) option to ls-tree. I need it so that the merge-trees (formerly known as git-merge.perl) script does not need to create any temporary dircache while merging. It used to use show-files on a temporary dircache to get the list of files in the ancestor tree, and also used the dircache to store the result of its automerge. I probably still need it for the latter reason, but with this patch not for the former reason anymore. It is relative to bb95843a5a0f397270819462812735ee29796fb4 Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-15 17:37:05 +02:00
[PATCH] ls-tree matching multiple paths Enhance git-ls-tree to allow optional 'match paths' that restricts the output of git-ls-tree. This is useful to retrieve a single file's SHA1 out of a tree without creating an index. [JC: I added the test case] Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-26 19:52:50 +02:00
if (argc < 2)
[PATCH] Un unoptimize ls-tree behaviour ls-tree unconditionally called read_sha1_file() for all paths even when not needed, which was a mistake introduced by me. Rectify this by first checking S_ISDIR(mode) and read the tree contents only when it is a tree and we are recursive. There is no need to read it in any other cases. The patch also removes the confusing comment that led to this incorrect implementation. Thanks to Peter Baudis for noticing this problem. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 22:57:39 +02:00
usage(ls_tree_usage);
Add "get_sha1()" helper function. This allows the programs to use various simplified versions of the SHA1 names, eg just say "HEAD" for the SHA1 pointed to by the .git/HEAD file etc. For example, this commit has been done with git-commit-tree $(git-write-tree) -p HEAD instead of the traditional "$(cat .git/HEAD)" syntax.
2005-05-02 01:36:56 +02:00
if (get_sha1(argv[1], sha1) < 0)
[PATCH] Un unoptimize ls-tree behaviour ls-tree unconditionally called read_sha1_file() for all paths even when not needed, which was a mistake introduced by me. Rectify this by first checking S_ISDIR(mode) and read the tree contents only when it is a tree and we are recursive. There is no need to read it in any other cases. The patch also removes the confusing comment that led to this incorrect implementation. Thanks to Peter Baudis for noticing this problem. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 22:57:39 +02:00
usage(ls_tree_usage);
[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 09:05:38 +02:00
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 07:48:08 +01:00
pathspec = get_pathspec(prefix, argv + 2);
Only use a single parser for tree objects This makes read_tree_recursive and read_tree take a struct tree instead of a buffer. It also move the declaration of read_tree into tree.h (where struct tree is defined), and updates ls-tree and diff-index (the only places that presently use read_tree*()) to use the new versions. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26 07:13:36 +01:00
tree = parse_tree_indirect(sha1);
if (!tree)
ls-tree: major rewrite to do pathspec git-ls-tree should be rewritten to use a pathspec the same way everybody else does. Right now it's the odd man out: if you do git-ls-tree HEAD divers/char drivers/ it will show the same files _twice_, which is not how pathspecs in general work. How about this patch? It breaks some of the git-ls-tree tests, but it makes git-ls-tree work a lot more like other git pathspec commands, and it removes more than 150 lines by re-using the recursive tree traversal (but the "-d" flag is gone for good, so I'm not pushing this too hard). Linus
2005-11-26 18:38:20 +01:00
die("not a tree object");
Only use a single parser for tree objects This makes read_tree_recursive and read_tree take a struct tree instead of a buffer. It also move the declaration of read_tree into tree.h (where struct tree is defined), and updates ls-tree and diff-index (the only places that presently use read_tree*()) to use the new versions. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26 07:13:36 +01:00
read_tree_recursive(tree, "", 0, 0, pathspec, show_tree);
ls-tree: major rewrite to do pathspec git-ls-tree should be rewritten to use a pathspec the same way everybody else does. Right now it's the odd man out: if you do git-ls-tree HEAD divers/char drivers/ it will show the same files _twice_, which is not how pathspecs in general work. How about this patch? It breaks some of the git-ls-tree tests, but it makes git-ls-tree work a lot more like other git pathspec commands, and it removes more than 150 lines by re-using the recursive tree traversal (but the "-d" flag is gone for good, so I'm not pushing this too hard). Linus
2005-11-26 18:38:20 +01:00
[PATCH] ls-tree for listing trees ls-tree tool provides just a way to export the binary tree objects to a usable text format. This is bound to be useful in variety of scripts, although none of those I have currently uses it. But e.g. the simple script I've sent to HPA for purging the object database uses it. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-13 11:02:34 +02:00
return 0;
}
Copy permalink