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>
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>
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>
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>
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>
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>
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
To get more a "git-ls-files" approach, this trivial patch (on top of my
previous one) enables recursion, and doesn't show partial trees.
[jc: after further discussion, this version enables recursion by default,
and you can disable it with "-d" flag.
git-ls-tree -d HEAD Documentation/no/such/directory
shows Documentation tree (without -d it shows nothing).
git-ls-tree HEAD
shows everything from the tree. Only to get the single level from the top
git-ls-tree -d HEAD
is needed. But there is no way to get the single level with pathspec.
You need to extract the object name of Documentation tree from the parent
tree and run
git-ls-tree -d $tree_id_of_Documentation_tree
to get something similar to what you can get from the current
git-ls-tree HEAD Documentation
]
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
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>
All usage strings are now declared as static const char [].
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the problem with ls-tree which failed to show
"drivers/char" directory when the user asked for "drivers/char/"
from the command line. At the same time, if "drivers/char" were
a non directory, "drivers/char/" would not show it. This is
consistent with the way diffcore-pathspec has been recently
fixed.
This adds back the diffcore-pathspec test,dropped when my
earlier diffcore-pathspec fix was rejected.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
Use SP as the column separator except the ones before path which
uses TAB, to make the output format consistent across ls-* and
diff-* commands.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
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.
Fixes all in-code names that leaved during "big name change".
Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- Raw hashes should be unsigned char.
- String functions want signed char.
- Hash and compress functions want unsigned char.
Signed-off By: Brian Gerst <bgerst@didntduck.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
cleanup: this patch adds a free() to ls-tree.c.
(Technically it's not a memory leak yet because the buffer is allocated
once by the function and then the utility exits - but it's a tad cleaner
to not leave such assumptions in the code, so that if someone reuses the
function (or extends the utility to include a loop) the uncleanliness
doesnt develop into a real memory leak.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Forward-ported.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Some commands initialize sha1_file_directory by hand. There is no
need to do so; sha1_file.c knows how to handle it.
The next patch will remove the variable altogether.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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.
This patch renames read_tree_with_tree_or_commit_sha1() to
read_object_with_reference() and extends it to automatically
dereference not just "commit" objects but "tag" objects. With
this patch, you can say e.g.:
ls-tree $tag
read-tree -m $(merge-base $tag $HEAD) $tag $HEAD
diff-cache $tag
diff-tree $tag $HEAD
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Updates ls-tree.c to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
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>
Now there is error() for "library" errors and die() for fatal "application"
errors. usage() is now used strictly only for usage errors.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
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>
