|
|
|
|
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] [--full-tree] [--abbrev[=<n>]]
|
|
|
|
|
<tree-ish> [<path>...]
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
|
|
|
|
Lists the contents of a given tree object, like what "/bin/ls -a" does
|
|
|
|
|
in the current working directory. Note that:
|
|
|
|
|
|
|
|
|
|
- the behaviour is slightly different from that of "/bin/ls" in that the
|
|
|
|
|
'<path>' denotes 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.
|
|
|
|
|
|
|
|
|
|
- the behaviour is similar to that of "/bin/ls" in that the '<path>' is
|
|
|
|
|
taken as relative to the current working directory. E.g. when you are
|
|
|
|
|
in a directory 'sub' that has a directory 'dir', you can run 'git
|
|
|
|
|
ls-tree -r HEAD dir' to list the contents of the tree (that is
|
|
|
|
|
`sub/dir` in `HEAD`). You don't want to give a tree that is not at the
|
|
|
|
|
root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
|
|
|
|
|
would result in asking for `sub/sub/dir` in the `HEAD` commit.
|
|
|
|
|
However, the current working directory can be ignored by passing
|
|
|
|
|
--full-tree option.
|
|
|
|
|
|
|
|
|
|
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 and do not quote filenames.
|
|
|
|
|
See OUTPUT FORMAT below for more information.
|
|
|
|
|
|
|
|
|
|
--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 a partial 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.
|
|
|
|
|
|
|
|
|
|
--full-tree::
|
|
|
|
|
Do not limit the listing to the current working directory.
|
|
|
|
|
Implies --full-name.
|
|
|
|
|
|
|
|
|
|
[<path>...]::
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
This output format is compatible with what `--index-info --stdin` of
|
|
|
|
|
'git update-index' expects.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Without the `-z` option, pathnames with "unusual" characters are
|
|
|
|
|
quoted as explained for the configuration variable `core.quotePath`
|
|
|
|
|
(see linkgit:git-config[1]). Using `-z` the filename is output
|
|
|
|
|
verbatim and the line is terminated by a NUL byte.
|
|
|
|
|
|
|
|
|
|
GIT
|
|
|
|
|
---
|
|
|
|
|
Part of the linkgit:git[1] suite
|
