The field is not used anymore, after the recent ls-tree rewrite. Signed-off-by: Junio C Hamano <email@example.com>
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
Store pointers to referenced objects in a variable sized array instead of linked list. This cuts down memory usage of utilities which use object references; e.g., git-fsck-objects --full on the git.git repository consumes about 2 MB of memory tracked by Massif instead of 7 MB before the change. Object refs are still the biggest consumer of memory (57%), but the malloc overhead for a single block instead of a linked list is substantially smaller. Signed-off-by: Sergey Vlasov <firstname.lastname@example.org> Signed-off-by: Junio C Hamano <email@example.com>
Signed-off-by: Daniel Barkalow <firstname.lastname@example.org> Signed-off-by: Junio C Hamano <email@example.com>
In particular, warn about things like zero-padding of the mode bits, which is a big no-no, since it makes otherwise identical trees have different representations (and thus different SHA1 numbers). Also make the warnings more regular. Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
The same way the other pathspecs work. Also fix missing success return from the matching - not that anything actually uses this yet ;)
The same way "git-diff-tree" can limit its output to just a set of matches, we can read in just a partial tree for comparison purposes.
An earlier change to optimize directory-file conflict check broke what "read-tree --emu23" expects. This is fixed by this commit. (1) Introduces an explicit flag to tell add_cache_entry() not to check for conflicts and use it when reading an existing tree into an empty stage --- by definition this case can never introduce such conflicts. (2) Makes read-cache.c:has_file_name() and read-cache.c:has_dir_name() aware of the cache stages, and flag conflict only with paths in the same stage. Signed-off-by: Junio C Hamano <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
Make 'sha1' parameters const where possible Signed-off-by: Jason McMullan <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.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 <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
This adds knowledge of delta objects to fsck-cache and various object parsing code. A new switch to git-fsck-cache is provided to display the maximum delta depth found in a repository. Signed-off-by: Nicolas Pitre <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
Fix two potential leaks. Signed-off-by: Jonas Fonseca <email@example.com> Signed-off-by: Petr Baudis <firstname.lastname@example.org>
When "path" exists as a file or a symlink in the index, an attempt to add "path/file" is refused because it results in file vs directory conflict. Similarly when "path/file1", "path/file2", etc. exist, an attempt to add "path" as a file or a symlink is refused. With git-update-cache --replace, these existing entries that conflict with the entry being added are automatically removed from the cache, with warning messages. Signed-off-by: Junio C Hamano <email@example.com>
It turns out that parse_object() is loading and decompressing given object to free it just before calling the specific object parsing function which does mmap and decompress the same object again. This patch introduces the ability to parse specific objects directly from a memory buffer. Without this patch, running git-fsck-cache on the kernel repositorytake: real 0m13.006s user 0m11.421s sys 0m1.218s With this patch applied: real 0m8.060s user 0m7.071s sys 0m0.710s The performance increase is significant, and this is kind of a prerequisite for sane delta object support with fsck. Signed-off-by: Nicolas Pitre <firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com>
The tree object parsing used to get the executable bit wrong, and didn't know about symlinks. Also, fsck really wants the full mode value so that it can verify the other bits for sanity, so save it all in struct tree_entry.
This patch fixes memory leaks in parse_object() and related functions; these leaks were very noticeable when running git-fsck-cache. Signed-off-by: Sergey Vlasov <firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com>
We check the ordering of the entries, and we verify that none of the entries has a slash in it (this allows us to remove the hacky "has_full_path" member from the tree structure, since we now just test it by walking the tree entries instead).
Introduce xmalloc and xrealloc to die gracefully with a descriptive message when out of memory, rather than taking a SIGSEGV. Signed-off-by: Christopher Li<firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com>
That would SIGSEGV.
…re parsing. The type doesn't come from the parsing, the type also has to match the usage.
Otherwise we can have objects without a type, which is not good.
This adds the contents of trees to struct tree. Signed-Off-By: Daniel Barkalow <firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com>
Next step: make "diff-cache" use it.