summaryrefslogtreecommitdiff
path: root/builtin-ls-files.c
AgeCommit message (Collapse)AuthorFilesLines
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-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-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>