|
|
|
git-ls-tree(1)
|
|
|
|
==============
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-ls-tree - List the contents of a tree object
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
[verse]
|
|
|
|
'git-ls-tree' [-d] [-r] [-t] [-l] [-z]
|
|
|
|
[--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
|
|
|
|
<tree-ish> [paths...]
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
Lists the contents of a given tree object, like what "/bin/ls -a" does
|
|
|
|
in the current working directory. Note that the usage is subtly different,
|
|
|
|
though - 'paths' denote just a list of patterns to match, e.g. so specifying
|
|
|
|
directory name (without '-r') will behave differently, and order of the
|
|
|
|
arguments does not matter.
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
<tree-ish>::
|
|
|
|
Id of a tree-ish.
|
|
|
|
|
[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>
20 years ago
|
|
|
-d::
|
|
|
|
Show only the named tree entry itself, not its children.
|
[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>
20 years ago
|
|
|
|
|
|
|
-r::
|
|
|
|
Recurse into sub-trees.
|
|
|
|
|
|
|
|
-t::
|
|
|
|
Show tree entries even when going to recurse them. Has no effect
|
|
|
|
if '-r' was not passed. '-d' implies '-t'.
|
|
|
|
|
|
|
|
-l::
|
|
|
|
--long::
|
|
|
|
Show object size of blob (file) entries.
|
|
|
|
|
|
|
|
-z::
|
|
|
|
\0 line termination on output.
|
|
|
|
|
|
|
|
--name-only::
|
|
|
|
--name-status::
|
|
|
|
List only filenames (instead of the "long" output), one per line.
|
|
|
|
|
|
|
|
--abbrev[=<n>]::
|
|
|
|
Instead of showing the full 40-byte hexadecimal object
|
|
|
|
lines, show only handful hexdigits prefix.
|
|
|
|
Non default number of digits can be specified with --abbrev=<n>.
|
|
|
|
|
|
|
|
--full-name::
|
|
|
|
Instead of showing the path names relative to the current working
|
|
|
|
directory, show the full path names.
|
|
|
|
|
|
|
|
paths::
|
|
|
|
When paths are given, show them (note that this isn't really raw
|
|
|
|
pathnames, but rather a list of patterns to match). Otherwise
|
|
|
|
implicitly uses the root level of the tree as the sole path argument.
|
[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>
20 years ago
|
|
|
|
|
|
|
|
|
|
|
Output Format
|
|
|
|
-------------
|
[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>
20 years ago
|
|
|
<mode> SP <type> SP <object> TAB <file>
|
|
|
|
|
|
|
|
When the `-z` option is not used, TAB, LF, and backslash characters
|
|
|
|
in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
|
|
|
|
|
|
|
|
When the `-l` option is used, format changes to
|
|
|
|
|
|
|
|
<mode> SP <type> SP <object> SP <object size> TAB <file>
|
|
|
|
|
|
|
|
Object size identified by <object> is given in bytes, and right-justified
|
|
|
|
with minimum width of 7 characters. Object size is given only for blobs
|
|
|
|
(file) entries; for other entries `-` character is used in place of size.
|
|
|
|
|
|
|
|
|
|
|
|
Author
|
|
|
|
------
|
|
|
|
Written by Petr Baudis <pasky@suse.cz>
|
|
|
|
Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>,
|
|
|
|
another major rewrite by Linus Torvalds <torvalds@osdl.org>
|
|
|
|
|
|
|
|
Documentation
|
|
|
|
--------------
|
|
|
|
Documentation by David Greaves, Junio C Hamano and the git-list
|
|
|
|
<git@vger.kernel.org>.
|
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the linkgit:git[7] suite
|