summaryrefslogtreecommitdiff
path: root/builtin/ls-files.c
AgeCommit message (Collapse)AuthorFilesLines
2011-09-12rename pathspec_prefix() to common_prefix() and move to dir.[ch]Libravatar Clemens Buchacher1-1/+1
Also make common_prefix_len() static as this refactoring makes dir.c itself the only caller of this helper function. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-06remove prefix argument from pathspec_prefixLibravatar Clemens Buchacher1-1/+1
Passing a prefix to a function that is supposed to find the prefix is strange. And it's really only used if the pathspec is NULL. Make the callers handle this case instead. As we are always returning a fresh copy of a string (or NULL), change the type of the returned value to non-const "char *". Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-02commit: allow partial commits with relative pathsLibravatar Clemens Buchacher1-36/+2
In order to do partial commits, git-commit overlays a tree on the cache and checks pathspecs against the result. Currently, the overlaying is done using "prefix" which prevents relative pathspecs with ".." and absolute pathspec from matching when they refer to files not under "prefix" and absent from the index, but still in the tree (i.e. files staged for removal). The point of providing a prefix at all is performance optimization. If we say there is no common prefix for the files of interest, then we have to read the entire tree into the index. But even if we cannot use the working directory as a prefix, we can still figure out if there is a common prefix for all given paths, and use that instead. The pathspec_prefix() routine from ls-files.c does exactly that. Any use of global variables is removed from pathspec_prefix() so that it can be called from commit.c. Reported-by: Reuben Thomas <rrt@sc3d.org> Analyzed-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05pathspec: rename per-item field has_wildcard to use_wildcardLibravatar Junio C Hamano1-1/+1
As the point of the last change is to allow use of strings as literals no matter what characters are in them, "has_wildcard" does not match what we use this field for anymore. It is used to decide if the wildcard matching should be used, so rename it to match the usage better. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-25Convert read_tree{,_recursive} to support struct pathspecLibravatar Nguyễn Thái Ngọc Duy1-4/+5
This patch changes behavior of the two functions. Previously it does prefix matching only. Now it can also do wildcard matching. All callers are updated. Some gain wildcard matching (archive, checkout), others reset pathspec_item.has_wildcard to retain old behavior (ls-files, ls-tree as they are plumbing). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12Merge branch 'jn/git-cmd-h-bypass-setup'Libravatar Junio C Hamano1-0/+3
* jn/git-cmd-h-bypass-setup: update-index -h: show usage even with corrupt index merge -h: show usage even with corrupt index ls-files -h: show usage even with corrupt index gc -h: show usage even with broken configuration commit/status -h: show usage even with broken configuration checkout-index -h: show usage even in an invalid repository branch -h: show usage even in an invalid repository Conflicts: builtin/merge.c
2010-10-22ls-files -h: show usage even with corrupt indexLibravatar Nguyễn Thái Ngọc Duy1-0/+3
Part of a campaign to avoid git <command> -h being distracted by access to the repository. A caller hoping to use "git ls-files" with an alternate index as part of a repair operation may well use "git ls-files -h" to show usage while planning it out. [jn: with rewritten log message and tests] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-08Use parentheses and `...' where appropriateLibravatar Štěpán Němec1-1/+1
Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18Merge branch 'ar/string-list-foreach'Libravatar Junio C Hamano1-23/+22
* ar/string-list-foreach: Convert the users of for_each_string_list to for_each_string_list_item macro Add a for_each_string_list_item macro
2010-08-02ls-files: learn a debugging dump formatLibravatar Thomas Rast1-0/+9
Teach git-ls-files a new option --debug that just tacks all available data from the cache onto each file's line. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05Convert the users of for_each_string_list to for_each_string_list_item macroLibravatar Alex Riesen1-23/+22
The rule for selecting the candidates for conversion is: if the callback function returns only 0 (the condition for for_each_string_list to exit early), than it can be safely converted to the macro. A notable exception are the callers in builtin/remote.c. If converted, the readability in the file will suffer greately. Besides, the code is not very performance critical (at the moment, at least): it does output formatting of the list of remotes. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'jp/string-list-api-cleanup'Libravatar Junio C Hamano1-1/+1
* jp/string-list-api-cleanup: string_list: Fix argument order for string_list_append string_list: Fix argument order for string_list_lookup string_list: Fix argument order for string_list_insert_at_index string_list: Fix argument order for string_list_insert string_list: Fix argument order for for_each_string_list string_list: Fix argument order for print_string_list
2010-06-27string_list: Fix argument order for for_each_string_listLibravatar Julian Phillips1-1/+1
Update the definition and callers of for_each_string_list to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-05ls-files: allow relative pathspecLibravatar Clemens Buchacher1-34/+41
git ls-files used to error out if given paths which point outside the current working directory, such as '../'. We now allow such paths and the output is analogous to git grep -l. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-21ls: remove redundant logicLibravatar Erik Faye-Lund1-5/+2
find_unique_abbrev() already returns the full SHA-1 if abbrev = 0, so we can remove the logic that avoids the call. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+606
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>