summaryrefslogtreecommitdiff
path: root/builtin-ls-files.c
AgeCommit message (Collapse)AuthorFilesLines
2008-02-16Merge branch 'jc/gitignore-ends-with-slash'Libravatar Junio C Hamano1-2/+4
* jc/gitignore-ends-with-slash: gitignore: lazily find dtype gitignore(5): Allow "foo/" in ignore list to match directory "foo"
2008-02-05gitignore: lazily find dtypeLibravatar Junio C Hamano1-4/+4
When we process "foo/" entries in gitignore files on a system that does not have d_type member in "struct dirent", the earlier implementation ran lstat(2) separately when matching with entries that came from the command line, in-tree .gitignore files, and $GIT_DIR/info/excludes file. This optimizes it by delaying the lstat(2) call until it becomes absolutely necessary. The initial idea for this change was by Jeff King, but I optimized it further to pass pointers to around. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05gitignore(5): Allow "foo/" in ignore list to match directory "foo"Libravatar Junio C Hamano1-2/+4
A pattern "foo/" in the exclude list did not match directory "foo", but a pattern "foo" did. This attempts to extend the exclude mechanism so that it would while not matching a regular file or a symbolic link "foo". In order to differentiate a directory and non directory, this passes down the type of path being checked to excluded() function. A downside is that the recursive directory walk may need to run lstat(2) more often on systems whose "struct dirent" do not give the type of the entry; earlier it did not have to do so for an excluded path, but we now need to figure out if a path is a directory before deciding to exclude it. This is especially bad because an idea similar to the earlier CE_UPTODATE optimization to reduce number of lstat(2) calls would by definition not apply to the codepaths involved, as (1) directories will not be registered in the index, and (2) excluded paths will not be in the index anyway. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-21Make on-disk index representation separate from in-core oneLibravatar Linus Torvalds1-5/+5
This converts the index explicitly on read and write to its on-disk format, allowing the in-core format to contain more flags, and be simpler. In particular, the in-core format is now host-endian (as opposed to the on-disk one that is network endian in order to be able to be shared across machines) and as a result we can dispense with all the htonl/ntohl on accesses to the cache_entry fields. This will make it easier to make use of various temporary flags that do not exist in the on-disk format. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-22Export three helper functions from ls-filesLibravatar Junio C Hamano1-46/+52
This exports three helper functions from ls-files. * pathspec_match() checks if a given path matches a set of pathspecs and optionally records which pathspec was used. This function used to be called "match()" but renamed to be a bit less vague. * report_path_error() takes a set of pathspecs and the record pathspec_match() above leaves, and gives error message. This was split out of the main function of ls-files. * overlay_tree_on_cache() takes a tree-ish (typically "HEAD") and overlays it on the current in-core index. By iterating over the resulting index, the caller can find out the paths in either the index or the HEAD. This function used to be called "overlay_tree()" but renamed to be a bit more descriptive. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-15git-ls-files: add --exclude-standardLibravatar Jeff King1-2/+7
This provides a way for scripts to get at the new standard exclude function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05Use setup_work_tree() in builtin-ls-files.cLibravatar Mike Hommey1-5/+2
Signed-off-by: Mike Hommey <mh@glandium.org> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-03Merge branch 'ph/strbuf'Libravatar Junio C Hamano1-18/+4
* ph/strbuf: (44 commits) Make read_patch_file work on a strbuf. strbuf_read_file enhancement, and use it. strbuf change: be sure ->buf is never ever NULL. double free in builtin-update-index.c Clean up stripspace a bit, use strbuf even more. Add strbuf_read_file(). rerere: Fix use of an empty strbuf.buf Small cache_tree_write refactor. Make builtin-rerere use of strbuf nicer and more efficient. Add strbuf_cmp. strbuf_setlen(): do not barf on setting length of an empty buffer to 0 sq_quote_argv and add_to_string rework with strbuf's. Full rework of quote_c_style and write_name_quoted. Rework unquote_c_style to work on a strbuf. strbuf API additions and enhancements. nfv?asprintf are broken without va_copy, workaround them. Fix the expansion pattern of the pseudo-static path buffer. builtin-for-each-ref.c::copy_name() - do not overstep the buffer. builtin-apply.c: fix a tiny leak introduced during xmemdupz() conversion. Use xmemdupz() in many places. ...
2007-10-02Must not modify the_index.cache as it may be passed to realloc at some point.Libravatar Keith Packard1-1/+2
The index cache is not static, growing as new entries are added. If entries are added after prune_cache is called, cache will no longer point at the base of the allocation, and realloc will not be happy. I verified that this was the only place in the current source which modified any index_state.cache elements aside from the alloc/realloc calls in read-cache by changing the type of the element to 'struct cache_entry ** const cache' and recompiling. A more efficient patch would create a separate 'cache_base' value to track the allocation and then fix things up when reallocation was necessary, instead of the brute-force memmove used here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-20Full rework of quote_c_style and write_name_quoted.Libravatar Pierre Habouzit1-10/+3
* quote_c_style works on a strbuf instead of a wild buffer. * quote_c_style is now clever enough to not add double quotes if not needed. * write_name_quoted inherits those advantages, but also take a different set of arguments. Now instead of asking for quotes or not, you pass a "terminator". If it's \0 then we assume you don't want to escape, else C escaping is performed. In any case, the terminator is also appended to the stream. It also no longer takes the prefix/prefix_len arguments, as it's seldomly used, and makes some optimizations harder. * write_name_quotedpfx is created to work like write_name_quoted and take the prefix/prefix_len arguments. Thanks to those API changes, diff.c has somehow lost weight, thanks to the removal of functions that were wrappers around the old write_name_quoted trying to give it a semantics like the new one, but performing a lot of allocations for this goal. Now we always write directly to the stream, no intermediate allocation is performed. As a side effect of the refactor in builtin-apply.c, the length of the bar graphs in diffstats are not affected anymore by the fact that the path was clipped. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-18Use xmemdupz() in many places.Libravatar Pierre Habouzit1-8/+1
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-17git-commit: Allow partial commit of file removal.Libravatar Junio C Hamano1-0/+78
When making a partial commit, git-commit uses git-ls-files with the --error-unmatch option to expand and sanity check the user supplied path patterns. When any path pattern does not match with the paths known to the index, it errors out, in order to catch a common mistake to say "git commit Makefiel cache.h" and end up with a commit that touches only cache.h (notice the misspelled "Makefile"). This detection however does not work well when the path has already been removed from the index. If you drop a path from the index and try to commit that partially, i.e. $ git rm COPYING $ git commit -m 'Remove COPYING' COPYING the command complains because git does not know anything about COPYING anymore. This introduces a new option --with-tree to git-ls-files and uses it in git-commit when we build a temporary index to write a tree object for the partial commit. When --with-tree=<tree-ish> option is specified, names from the given tree are added to the set of names the index knows about, so we can treat COPYING file in the example as known. Of course, there is no reason to use "git rm" and git-aware people have long time done: $ rm COPYING $ git commit -m 'Remove COPYING' COPYING which works just fine. But this caused a constant confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-12git-commit: Allow partial commit of file removal.Libravatar Junio C Hamano1-0/+78
When making a partial commit, git-commit uses git-ls-files with the --error-unmatch option to expand and sanity check the user supplied path patterns. When any path pattern does not match with the paths known to the index, it errors out, in order to catch a common mistake to say "git commit Makefiel cache.h" and end up with a commit that touches only cache.h (notice the misspelled "Makefile"). This detection however does not work well when the path has already been removed from the index. If you drop a path from the index and try to commit that partially, i.e. $ git rm COPYING $ git commit -m 'Remove COPYING' COPYING the command complains because git does not know anything about COPYING anymore. This introduces a new option --with-tree to git-ls-files and uses it in git-commit when we build a temporary index to write a tree object for the partial commit. When --with-tree=<tree-ish> option is specified, names from the given tree are added to the set of names the index knows about, so we can treat COPYING file in the example as known. Of course, there is no reason to use "git rm" and git-aware people have long time done: $ rm COPYING $ git commit -m 'Remove COPYING' COPYING which works just fine. But this caused a constant confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-29ls-files --error-unmatch: do not barf if the same pattern is given twice.Libravatar Junio C Hamano1-0/+20
This is most visible when you do "git commit Makefile Makefile"; it may be a stupid request, but that is not a reason to fail the command. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01Clean up work-tree handlingLibravatar Johannes Schindelin1-3/+5
The old version of work-tree support was an unholy mess, barely readable, and not to the point. For example, why do you have to provide a worktree, when it is not used? As in "git status". Now it works. Another riddle was: if you can have work trees inside the git dir, why are some programs complaining that they need a work tree? IOW it is allowed to call $ git --git-dir=../ --work-tree=. bla when you really want to. In this case, you are both in the git directory and in the working tree. So, programs have to actually test for the right thing, namely if they are inside a working tree, and not if they are inside a git directory. Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was specified, unless there is a repository in the current working directory. It does now. The logic to determine if a repository is bare, or has a work tree (tertium non datur), is this: --work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true, which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR ends in /.git, which overrides the directory in which .git/ was found. In related news, a long standing bug was fixed: when in .git/bla/x.git/, which is a bare repository, git formerly assumed ../.. to be the appropriate git dir. This problem was reported by Shawn Pearce to have caused much pain, where a colleague mistakenly ran "git init" in "/" a long time ago, and bare repositories just would not work. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-01Merge branch 'ei/worktree+filter'Libravatar Junio C Hamano1-1/+1
* ei/worktree+filter: filter-branch: always export GIT_DIR if it is set setup_git_directory: fix segfault if repository is found in cwd test GIT_WORK_TREE extend rev-parse test for --is-inside-work-tree Use new semantics of is_bare/inside_git_dir/inside_work_tree introduce GIT_WORK_TREE to specify the work tree test git rev-parse rev-parse: introduce --is-bare-repository rev-parse: document --is-inside-git-dir
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+1
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06Use new semantics of is_bare/inside_git_dir/inside_work_treeLibravatar Matthias Lederhofer1-1/+1
Up to now to check for a working tree this was used: !is_bare && !inside_git_dir (the check for bare is redundant because is_inside_git_dir returned already 1 for bare repositories). Now the check is: inside_work_tree && !inside_git_dir Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-14Fix some "git ls-files -o" fallout from gitlinksLibravatar Linus Torvalds1-7/+25
Since "git ls-files" doesn't really pass down any details on what it really wants done to the directory walking code, the directory walking code doesn't really know whether the caller wants to know about gitlink directories, or whether it wants to just know about ignored files. So the directory walking code will return those gitlink directories unless the caller has explicitly told it not to ("dir->show_other_directories" tells the directory walker to only show "other" directories). This kind of confuses "git ls-files -o", because - it didn't really expect to see entries listed that were already in the index, unless they were unmerged, and would die on that unexpected setup, rather than just "continue". - it didn't know how to match directory entries with the final "/" This trivial change updates the "show_other_files()" function to handle both of these issues gracefully. There really was no reason to die, when the obviously correct thing for the function was to just ignore files it already knew about (that's what "other" means here!). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-31Optimize directory listing with pathspec limiter.Libravatar Linus Torvalds1-1/+1
The way things are set up, you can now pass a "pathspec" to the "read_directory()" function. If you pass NULL, it acts exactly like it used to do (read everything). If you pass a non-NULL pointer, it will simplify it into a "these are the prefixes without any special characters", and stop any readdir() early if the path in question doesn't match any of the prefixes. NOTE! This does *not* obviate the need for the caller to do the *exact* pathspec match later. It's a first-level filter on "read_directory()", but it does not do the full pathspec thing. Maybe it should. But in the meantime, builtin-add.c really does need to do first read_directory(dir, .., pathspec); if (pathspec) prune_directory(dir, pathspec, baselen); ie the "prune_directory()" part will do the *exact* pathspec pruning, while the "read_directory()" will use the pathspec just to do some quick high-level pruning of the directories it will recurse into. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Mechanical conversion to use prefixcmp()Libravatar Junio C Hamano1-4/+4
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Commands requiring a work tree must not run in GIT_DIRLibravatar Johannes Schindelin1-1/+9
This patch helps when you accidentally run something like git-clean in the git directory instead of the work tree. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-2/+0
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-01ls-files: Give hints when errors happen.Libravatar Andreas Ericsson1-1/+5
Without this patch "git commit file.c file2.c" produces the not so stellar output: error: pathspec 'file.c' did not match any. error: pathspec 'file2.c' did not match any. With this patch, the output is changed to: error: pathspec 'file.c' did not match any file(s) known to git. error: pathspec 'file2.c' did not match any file(s) known to git. Did you forget to 'git add'? Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15remove unnecessary initializationsLibravatar David Rientjes1-13/+14
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-31Fix up some fallout from "setup_git_directory()" cleanupsLibravatar Linus Torvalds1-8/+7
git-ls-files was broken by the setup_git_directory() calling changes, because I had missed the fact that the "prefix" variable in that file was static to the whole file, and unlike git-ls-tree (where I had fixed it up), it ended up using two different variables with the same name depending on what the scoping happened to be. This fixes it up properly (by just removing the static variable, and passing the automatic one around properly), and git-ls-files should work again. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-29Call setup_git_directory() much earlierLibravatar Linus Torvalds1-2/+1
This changes the calling convention of built-in commands and passes the "prefix" (i.e. pathname of $PWD relative to the project root level) down to them. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-23Merge branch 'jc/builtin-n-tar-tree' into nextLibravatar Junio C Hamano1-0/+499
* jc/builtin-n-tar-tree: Builtin git-diff-files, git-diff-index, git-diff-stages, and git-diff-tree. Builtin git-show-branch. Builtin git-apply. Builtin git-commit-tree. Builtin git-read-tree. Builtin git-tar-tree. Builtin git-ls-tree. Builtin git-ls-files.
2006-05-23Builtin git-ls-files.Libravatar Peter Eriksen1-0/+824
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>