summaryrefslogtreecommitdiff
path: root/builtin/ls-files.c
AgeCommit message (Collapse)AuthorFilesLines
2013-07-22Merge branch 'jx/clean-interactive'Libravatar Junio C Hamano1-7/+11
Add "interactive" mode to "git clean". The early part to refactor relative path related helper functions looked sensible. * jx/clean-interactive: test: run testcases with POSIX absolute paths on Windows test: add t7301 for git-clean--interactive git-clean: add documentation for interactive git-clean git-clean: add ask each interactive action git-clean: add select by numbers interactive action git-clean: add filter by pattern interactive action git-clean: use a git-add-interactive compatible UI git-clean: add colors to interactive git-clean git-clean: show items of del_list in columns git-clean: add support for -i/--interactive git-clean: refactor git-clean into two phases write_name{_quoted_relative,}(): remove redundant parameters quote_path_relative(): remove redundant parameter quote.c: substitute path_relative with relative_path path.c: refactor relative_path(), not only strip prefix test: add test cases for relative_path
2013-07-09Convert "struct cache_entry *" to "const ..." wherever possibleLibravatar Nguyễn Thái Ngọc Duy1-6/+6
I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-30Merge branch 'mh/ref-races'Libravatar Junio C Hamano1-5/+7
"git pack-refs" that races with new ref creation or deletion have been susceptible to lossage of refs under right conditions, which has been tightened up. * mh/ref-races: for_each_ref: load all loose refs before packed refs get_packed_ref_cache: reload packed-refs file when it changes add a stat_validity struct Extract a struct stat_data from cache_entry packed_ref_cache: increment refcount when locked do_for_each_entry(): increment the packed refs cache refcount refs: manage lifetime of packed refs cache via reference counting refs: implement simple transactions for the packed-refs file refs: wrap the packed refs cache in a level of indirection pack_refs(): split creation of packed refs and entry writing repack_without_ref(): split list curation and entry writing
2013-06-26write_name{_quoted_relative,}(): remove redundant parametersLibravatar Jiang Xin1-9/+8
After substitute path_relative() in quote.c with relative_path() from path.c, parameters (such as len and prefix_len) are redundant in function write_name() and write_name_quoted_relative(). The callers have already been audited that the strings they pass are properly NUL terminated and the length they give are the length of the string (or -1 that asks the length to be counted by the callee). Remove these now-redundant parameters. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26quote_path_relative(): remove redundant parameterLibravatar Jiang Xin1-1/+1
quote_path_relative() used to take a counted string as its parameter (the string to be quoted). With an earlier change, it now uses relative_path() that does not take a counted string, and we have been passing only the pointer to the string since then. Remove the length parameter from quote_path_relative() to show that this parameter was redundant. All the changed lines show that the caller passed either -1 (to ask the function run strlen() on the string), or the length of the string, so the earlier conversion was safe. All the callers of quote_path_relative() that used to take counted string have been audited to make sure that they are passing length of the actual string (or -1 to ask the callee run strlen()) Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26quote.c: substitute path_relative with relative_pathLibravatar Jiang Xin1-2/+7
Substitute the function path_relative in quote.c with the function relative_path. Function relative_path can be treated as an enhanced and more robust version of path_relative. Outputs of path_relative and it's replacement (relative_path) are the same for the following cases: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b/ c/ c/ /a/b/c /a/b/ c c /a/ /a/b/ ../ ../ / /a/b/ ../../ ../../ /a/c /a/b/ ../c ../c /x/y /a/b/ ../../x/y ../../x/y a/b/c/ a/b/ c/ c/ a/ a/b/ ../ ../ x/y a/b/ ../../x/y ../../x/y /a/b (empty) /a/b /a/b /a/b (null) /a/b /a/b a/b (empty) a/b a/b a/b (null) a/b a/b But if both of the path and the prefix are the same, or the returned relative path should be the current directory, the outputs of both functions are different. Function relative_path returns "./", while function path_relative returns empty string. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/ /a/b/ (empty) ./ a/b/ a/b/ (empty) ./ (empty) (null) (empty) ./ (empty) (empty) (empty) ./ But the callers of path_relative can handle such cases, or never encounter this issue at all, because: * In function quote_path_relative, if the output of path_relative is empty, append "./" to it, like: if (!out->len) strbuf_addstr(out, "./"); * Another caller is write_name_quoted_relative, which is only used by builtin/ls-files.c. git-ls-files only show files, so path of files will never be identical with the prefix of a directory. The following differences show that path_relative does not handle extra slashes properly: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a//b//c/ //a/b// ../../../../a//b//c/ c/ a/b//c a//b ../b//c c And if prefix has no trailing slash, path_relative does not work properly either. But since prefix always has a trailing slash, it's not a problem. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b b/c/ c/ /a/b /a/b b ./ /a/b/ /a/b b/ ./ /a /a/b/ ../../a ../ a/b/c/ a/b b/c/ c/ a/b/ a/b b/ ./ a a/b ../a ../ x/y a/b/ ../x/y ../../x/y a/c a/b c ../c /a/ /a/b (empty) ../ (empty) /a/b ../../ ./ One tricky part in this conversion is write_name() function in ls-files.c. It takes a counted string, <name, len>, that is to be made relative to <prefix, prefix_len> and then quoted. Because write_name_quoted_relative() still takes these two parameters as counted string, but ignores the count and treat these two as NUL-terminated strings, this conversion needs to be audited for its callers: - For <name, len>, all three callers of write_name() passes a NUL-terminated string and its true length, so this patch makes "len" unused. - For <prefix, prefix_len>, prefix could be a string that is longer than empty while prefix_len could be 0 when "--full-name" option is used. This is fixed by checking prefix_len in write_name() and calling write_name_quoted_relative() with NULL when prefix_len is set to 0. Again, this makes "prefix_len" given to write_name_quoted_relative() unused, without introducing a bug. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-20Extract a struct stat_data from cache_entryLibravatar Michael Haggerty1-5/+7
Add public functions fill_stat_data() and match_stat_data() to work with it. This infrastructure will later be used to check the validity of other types of file. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-13use logical OR (||) instead of binary OR (|) in logical contextLibravatar René Scharfe1-4/+4
The compiler can short-circuit the evaluation of conditions strung together with logical OR operators instead of computing the resulting bitmask with binary ORs. More importantly, this patch makes the intent of the changed code clearer, because the logical context (as opposed to binary context) becomes immediately obvious. While we're at it, simplify the check for patch->is_rename in builtin/apply.c a bit; it can only be 0 or 1, so we don't need a comparison operator. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15dir.c: replace is_path_excluded with now equivalent is_excluded APILibravatar Karsten Blees1-11/+4
Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-4/+11
Add a new command "git check-ignore" for debugging .gitignore files. The variable names may want to get cleaned up but that can be done in-tree. * as/check-ignore: clean.c, ls-files.c: respect encapsulation of exclude_list_groups t0008: avoid brace expansion add git-check-ignore sub-command setup.c: document get_pathspec() add.c: extract new die_if_path_beyond_symlink() for reuse add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse pathspec.c: rename newly public functions for clarity add.c: move pathspec matchers into new pathspec.c for reuse add.c: remove unused argument from validate_pathspec() dir.c: improve docs for match_pathspec() and match_pathspec_depth() dir.c: provide clear_directory() for reclaiming dir_struct memory dir.c: keep track of where patterns came from dir.c: use a single struct exclude_list per source of excludes Conflicts: builtin/ls-files.c dir.c
2013-01-16clean.c, ls-files.c: respect encapsulation of exclude_list_groupsLibravatar Adam Spiers1-5/+10
Consumers of the dir.c traversal API should avoid assuming knowledge of the internal implementation of exclude_list_groups. Therefore when adding items to an exclude list, it should be accessed via the pointer returned from add_exclude_list(), rather than by referencing a location within dir.exclude_list_groups[EXC_CMDL]. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10Merge branch 'as/dir-c-cleanup'Libravatar Junio C Hamano1-1/+1
Refactor and generally clean up the directory traversal API implementation. * as/dir-c-cleanup: dir.c: rename free_excludes() to clear_exclude_list() dir.c: refactor is_path_excluded() dir.c: refactor is_excluded() dir.c: refactor is_excluded_from_list() dir.c: rename excluded() to is_excluded() dir.c: rename excluded_from_list() to is_excluded_from_list() dir.c: rename path_excluded() to is_path_excluded() dir.c: rename cryptic 'which' variable to more consistent name Improve documentation and comments regarding directory traversal API api-directory-listing.txt: update to match code
2013-01-06dir.c: keep track of where patterns came fromLibravatar Adam Spiers1-2/+3
For exclude patterns read in from files, the filename is stored in the exclude list, and the originating line number is stored in the individual exclude (counting starting at 1). For exclude patterns provided on the command line, a string describing the source of the patterns is stored in the exclude list, and the sequence number assigned to each exclude pattern is negative, with counting starting at -1. So for example the 2nd pattern provided via --exclude would be numbered -2. This allows any future consumers of that data to easily distinguish between exclude patterns from files vs. from the CLI. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-06dir.c: use a single struct exclude_list per source of excludesLibravatar Adam Spiers1-3/+5
Previously each exclude_list could potentially contain patterns from multiple sources. For example dir->exclude_list[EXC_FILE] would typically contain patterns from .git/info/exclude and core.excludesfile, and dir->exclude_list[EXC_DIRS] could contain patterns from multiple per-directory .gitignore files during directory traversal (i.e. when dir->exclude_stack was more than one item deep). We split these composite exclude_lists up into three groups of exclude_lists (EXC_CMDL / EXC_DIRS / EXC_FILE as before), so that each exclude_list now contains patterns from a single source. This will allow us to cleanly track the origin of each pattern simply by adding a src field to struct exclude_list, rather than to struct exclude, which would make memory management of the source string tricky in the EXC_DIRS case where its contents are dynamically generated. Similarly, by moving the filebuf member from struct exclude_stack to struct exclude_list, it allows us to track and subsequently free memory buffers allocated during the parsing of all exclude files, rather than only tracking buffers allocated for files in the EXC_DIRS group. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-28dir.c: rename path_excluded() to is_path_excluded()Libravatar Adam Spiers1-1/+1
Start adopting clearer names for exclude functions. This 'is_*' naming pattern for functions returning booleans was agreed here: http://thread.gmane.org/gmane.comp.version-control.git/204661/focus=204924 Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-19pathspec: save the non-wildcard length partLibravatar Nguyễn Thái Ngọc Duy1-1/+1
We mark pathspec with wildcards with the field use_wildcard. We could do better by saving the length of the non-wildcard part, which can be used for optimizations such as f9f6e2c (exclude: do strcmp as much as possible before fnmatch - 2012-06-07). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: ls-files: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-27/+27
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-05path_excluded(): update API to less cache-entry centricLibravatar Junio C Hamano1-2/+8
It was stupid of me to make the API too much cache-entry specific; the caller may want to check arbitrary pathname without having a corresponding cache-entry to see if a path is ignored. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03ls-files -i: pay attention to exclusion of leading pathsLibravatar Junio C Hamano1-6/+11
"git ls-files --exclude=t/ -i" does not show paths in directory t/ that have been added to the index, but it should. The excluded() API was designed for callers who walk the tree from the top, checking each level of the directory hierarchy as it descends if it is excluded, and not even bothering to recurse into an excluded directory. This would allow us optimize for a common case by not having to check if the exclude pattern "foo/" matches when looking at "foo/bar", because the caller should have noticed that "foo" is excluded and did not even bother to read "foo/bar" out of opendir()/readdir() to call it. The code for "ls-files -i" however walks the index linearly, feeding paths without checking if the leading directory is already excluded. Introduce a helper function path_excluded() to let this caller properly call excluded() check for higher hierarchies as necessary. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'cb/common-prefix-unification'Libravatar Junio C Hamano1-1/+1
* cb/common-prefix-unification: rename pathspec_prefix() to common_prefix() and move to dir.[ch] consolidate pathspec_prefix and common_prefix remove prefix argument from pathspec_prefix
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-23Merge branch 'cb/maint-ls-files-error-report'Libravatar Junio C Hamano1-3/+7
* cb/maint-ls-files-error-report: ls-files: fix pathspec display on error
2011-08-11ls-files: fix pathspec display on errorLibravatar Clemens Buchacher1-3/+7
The following sequence of commands reveals an issue with error reporting of relative paths: $ mkdir sub $ cd sub $ git ls-files --error-unmatch ../bbbbb error: pathspec 'b' did not match any file(s) known to git. $ git commit --error-unmatch ../bbbbb error: pathspec 'b' did not match any file(s) known to git. This bug is visible only if the normalized path (i.e., the relative path from the repository root) is longer than the prefix. Otherwise, the code skips over the normalized path and reads from an unused memory location which still contains a leftover of the original command line argument. So instead, use the existing facilities to deal with relative paths correctly. Also fix inconsistency between "checkout" and "commit", e.g. $ cd Documentation $ git checkout nosuch.txt error: pathspec 'Documentation/nosuch.txt' did not match... $ git commit nosuch.txt error: pathspec 'nosuch.txt' did not match... by propagating the prefix down the codepath that reports the error. 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>