summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-05-28cmd_diff(): make it obvious which cases are exclusive of each otherLibravatar Michael Haggerty1-5/+4
At first glance the OBJ_COMMIT, OBJ_TREE, and OBJ_BLOB cases look like they might be mutually exclusive. But the OBJ_COMMIT case doesn't end the loop iteration with "continue" like the other two cases, but rather falls through. So use if...else if...else construct to make it more obvious that only the last two cases are mutually exclusive. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28cmd_diff(): rename local variable "list" -> "entry"Libravatar Michael Haggerty1-4/+4
It's not a list, it's an array entry. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28cmd_diff(): use an object_array for holding treesLibravatar Michael Haggerty1-19/+18
Change cmd_diff() to use a (struct object_array) for holding the trees that it accumulates, rather than rolling its own equivalent. Incidentally, this change removes a hard-coded limit of 100 trees in combined diff, not that it matters in practice. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28builtin_diff_tree(): make it obvious that function wants two entriesLibravatar Michael Haggerty1-9/+10
Instead of accepting an array and using exactly two elements from the array, take two single (struct object_array_entry *) arguments. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28fetch: make own copies of refnamesLibravatar Michael Haggerty1-2/+2
Do not retain references to refnames passed to the each_ref_fn callback add_existing(), because their lifetime is not guaranteed. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28describe: make own copy of refnameLibravatar Michael Haggerty1-2/+4
Do not retain a reference to the refname passed to the each_ref_fn callback get_name(), because there is no guarantee of the lifetimes of these names. Instead, make a local copy when needed. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-06Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-1/+5
* jk/merge-tree-added-identically: merge-tree: handle directory/empty conflict correctly
2013-05-06merge-tree: handle directory/empty conflict correctlyLibravatar John Keeping1-1/+5
git-merge-tree causes a null pointer dereference when a directory entry exists in only one or two of the three trees being compared with no corresponding entry in the other tree(s). When this happens, we want to handle the entry as a directory and not attempt to mark it as a file merge. Do this by setting the entries bit in the directory mask when the entry is missing or when it is a directory, only performing the file comparison when we know that a file entry exists. Reported-by: Andreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: John Keeping <john@keeping.me.uk> Tested-by: Andreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01Merge branch 'tr/remote-tighten-commandline-parsing'Libravatar Junio C Hamano1-1/+1
* tr/remote-tighten-commandline-parsing: remote: 'show' and 'prune' can take more than one remote remote: check for superfluous arguments in 'git remote add' remote: add a test for extra arguments, according to docs
2013-04-28Merge branch 'jk/check-corrupt-objects-carefully'Libravatar Junio C Hamano1-1/+1
* jk/check-corrupt-objects-carefully: clone: Make the 'junk_mode' symbol a file static
2013-04-28clone: Make the 'junk_mode' symbol a file staticLibravatar Ramsay Jones1-1/+1
Sparse issues an "'junk_mode' not declared. Should it be static?" warning. In order to suppress the warning, since this symbol does not need more than file visibility, we simply add the static modifier to its declaration. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-1/+1
off-by-one fix. * jk/merge-tree-added-identically: merge-tree: fix typo in "both changed identically"
2013-04-28merge-tree: fix typo in "both changed identically"Libravatar John Keeping1-1/+1
Commit aacecc3 (merge-tree: don't print entries that match "local" - 2013-04-07) had a typo causing the "same in both" check to be incorrect and check if both the base and "their" versions are removed instead of checking that both the "our" and "their" versions are removed. Fix this. Reported-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Test-written-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-26Merge branch 'rr/shortlog-doc'Libravatar Junio C Hamano2-4/+2
Update documentation for "log" and "shortlog". * rr/shortlog-doc: builtin/shortlog.c: make usage string consistent with log builtin/log.c: make usage string consistent with doc git-shortlog.txt: make SYNOPSIS match log, update OPTIONS git-log.txt: rewrite note on why "--" may be required git-log.txt: generalize <since>..<until> git-log.txt: order OPTIONS properly; move <since>..<until> revisions.txt: clarify the .. and ... syntax git-shortlog.txt: remove (-h|--help) from OPTIONS
2013-04-26Merge branch 'jc/add-ignore-removal'Libravatar Junio C Hamano1-6/+17
Introduce "--ignore-removal" as a synonym to "--no-all" for "git add", and improve the 2.0 migration warning with it. * jc/add-ignore-removal: git add: rephrase -A/--no-all warning git add: --ignore-removal is a better named --no-all
2013-04-26Merge branch 'jc/warn-pathless-add-finishing-touches'Libravatar Junio C Hamano1-0/+2
* jc/warn-pathless-add-finishing-touches: git add: avoid "-u/-A without pathspec" warning on stat-dirty paths
2013-04-26git add: avoid "-u/-A without pathspec" warning on stat-dirty pathsLibravatar Junio C Hamano1-0/+2
In preparation for Git 2.0, "git add -u/-A" without pathspec checks all the working tree (not limited to the current directory) and issues a warning when it finds any path that we might add in Git 2.0, because that would mean the users' fingers need to be trained to explicitly say "." if they want to keep the current behaviour. However, the check was incomplete, because "git add" usually does not refresh the index, considers a path that is stat-dirty but has contents that is otherwise up-to-date in the index as "we might add", and relies on that it is a no-op to add the same thing again via the add_file_to_index() API (which also knows not to say "added" in verbose mode when this happens). We do not want to trigger the warning for a path that is outside the current directory is merely stat-dirty, as it won't be added in Git 2.0, either. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
2013-04-24Merge branch 'jk/remote-helper-with-signed-tags'Libravatar Junio C Hamano1-1/+7
Allows remote-helpers to declare they can handle signed tags, and issue a warning when using those that don't. * jk/remote-helper-with-signed-tags: transport-helper: add 'signed-tags' capability transport-helper: pass --signed-tags=warn-strip to fast-export fast-export: add --signed-tags=warn-strip mode
2013-04-24Sync with maintLibravatar Junio C Hamano1-2/+2
* maint: Update draft release notes to 1.8.2.2 completion: remove duplicate block for "git commit -c" cherry-pick/revert: make usage say '<commit-ish>...'
2013-04-24Merge branch 'jc/merge-tag-object' into maintLibravatar Junio C Hamano1-0/+13
"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. Make the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit
2013-04-24remote: check for superfluous arguments in 'git remote add'Libravatar Thomas Rast1-1/+1
The 'git remote add' subcommand did not check for superfluous command line arguments. Make it so. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24cherry-pick/revert: make usage say '<commit-ish>...'Libravatar Kevin Bracey1-2/+2
The usage string for cherry-pick and revert has never been updated to reflect their ability to handle multiple commits. Other documentation is already correct. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-23Merge branch 'nd/pretty-formats'Libravatar Junio C Hamano2-2/+2
pretty-printing body of the commit that is stored in non UTF-8 encoding did not work well. The early part of this series fixes it. And then it adds %C(auto) specifier that turns the coloring on when we are emitting to the terminal, and adds column-aligning format directives. * nd/pretty-formats: pretty: support %>> that steal trailing spaces pretty: support truncating in %>, %< and %>< pretty: support padding placeholders, %< %> and %>< pretty: add %C(auto) for auto-coloring pretty: split color parsing into a separate function pretty: two phase conversion for non utf-8 commits utf8.c: add reencode_string_len() that can handle NULs in string utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences utf8.c: move display_mode_esc_sequence_len() for use by other functions pretty: share code between format_decoration and show_decorations pretty-formats.txt: wrap long lines pretty: get the correct encoding for --pretty:format=%e pretty: save commit encoding from logmsg_reencode if the caller needs it
2013-04-23Merge branch 'kb/status-ignored-optim-2'Libravatar Junio C Hamano3-21/+6
Fixes a handful of issues in the code to traverse working tree to find untracked and/or ignored files, cleans up and optimizes the codepath in general. * kb/status-ignored-optim-2: dir.c: git-status --ignored: don't scan the work tree twice dir.c: git-status --ignored: don't scan the work tree three times dir.c: git-status: avoid is_excluded checks for tracked files dir.c: replace is_path_excluded with now equivalent is_excluded API dir.c: unify is_excluded and is_path_excluded APIs dir.c: move prep_exclude dir.c: factor out parts of last_exclude_matching for later reuse dir.c: git-clean -d -X: don't delete tracked directories dir.c: make 'git-status --ignored' work within leading directories dir.c: git-status --ignored: don't list empty directories as ignored dir.c: git-ls-files --directories: don't hide empty directories dir.c: git-status --ignored: don't list empty ignored directories dir.c: git-status --ignored: don't list files in ignored directories dir.c: git-status --ignored: don't drop ignored directories
2013-04-23Merge branch 'jk/receive-pack-deadlocks-with-early-failure'Libravatar Junio C Hamano1-1/+4
When receive-pack detects error in the pack header it received in order to decide which of unpack-objects or index-pack to run, it returned without closing the error stream, which led to a hang sideband thread. * jk/receive-pack-deadlocks-with-early-failure: receive-pack: close sideband fd on early pack errors
2013-04-22git add: rephrase -A/--no-all warningLibravatar Junio C Hamano1-6/+6
Now we have a synonym --ignore-removal for --no-all, we can rephrase the Git 2.0 transition warning message in a more natural way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22git add: --ignore-removal is a better named --no-allLibravatar Junio C Hamano1-0/+11
In the historical context of "git add --all ." that pays attention to "all kinds of changes" (implying "without ignoring removals"), the option to countermand it "--no-all" may have made sense, but because we will be making "--all" the default when a pathspec is given, it makes more sense to rename the option to a more explicit "--ignore-removal". The "--all" option naturally becomes its negation, "--no-ignore-removal". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22Merge branch 'jk/show-branch-strbuf' into maintLibravatar Junio C Hamano1-9/+8
* jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer
2013-04-22Merge branch 'jc/apply-ws-fix-tab-in-indent' into maintLibravatar Junio C Hamano1-6/+10
* jc/apply-ws-fix-tab-in-indent: test: resurrect q_to_tab apply --whitespace=fix: avoid running over the postimage buffer
2013-04-22Merge branch 'as/clone-reference-with-gitfile'Libravatar Junio C Hamano1-3/+13
"git clone" did not work if a repository pointed at by the "--reference" option is a gitfile that points at another place. * as/clone-reference-with-gitfile: clone: Allow repo using gitfile as a reference clone: Fix error message for reference repository
2013-04-22Merge branch 'jc/add-2.0-delete-default' (early part)Libravatar Junio C Hamano1-28/+87
Preparatory steps to make "git add <pathspec>" take notice of removed paths that match <pathspec> by default in Git 2.0. * 'jc/add-2.0-delete-default' (early part): git add: rephrase the "removal will cease to be ignored" warning git add: rework the logic to warn "git add <pathspec>..." default change git add: start preparing for "git add <pathspec>..." to default to "-A" builtin/add.c: simplify boolean variables
2013-04-22Merge branch 'nd/checkout-keep-sparse'Libravatar Junio C Hamano1-0/+5
Make the initial "sparse" selection of the paths more sticky across "git checkout". * nd/checkout-keep-sparse: checkout: add --ignore-skip-worktree-bits in sparse checkout mode
2013-04-22Merge branch 'jk/chopped-ident'Libravatar Junio C Hamano2-74/+8
A commit object whose author or committer ident are malformed crashed some code that trusted that a name, an email and an timestamp can always be found in it. * jk/chopped-ident: blame: handle broken commit headers gracefully pretty: handle broken commit headers gracefully cat-file: print tags raw for "cat-file -p"
2013-04-22builtin/shortlog.c: make usage string consistent with logLibravatar Ramkumar Ramachandra1-3/+1
"--" is used to separate pathspecs from the rev specs, and not rev specs from the options, as the shortlog_usage string currently indicates. In correcting this usage string, make it consistent with the log_usage string. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22builtin/log.c: make usage string consistent with docLibravatar Ramkumar Ramachandra1-1/+1
Replace '<since>..<until>' with '<revision range>', in accordance with the documentation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21git add: rephrase the "removal will cease to be ignored" warningLibravatar Junio C Hamano1-7/+14
Now the logic to decide when to warn has been tightened, we know the user is in a situation where the current and future behaviours will be different. Spell out what happens with these two versions and how to explicitly ask for the behaviour, and suggest "git status" as a way to inspect the current status. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19receive-pack: close sideband fd on early pack errorsLibravatar Jeff King1-1/+4
Since commit a22e6f8 (receive-pack: send pack-processing stderr over sideband, 2012-09-21), receive-pack will start an async sideband thread to copy the stderr from our index-pack or unpack-objects child to the client. We hand the thread's input descriptor to unpack(), which puts it in the "err" member of the "struct child_process". After unpack() returns, we use finish_async() to reap the sideband thread. The thread is only ready to die when it gets EOF on its pipe, which is connected to the err descriptor. So we expect all of the write ends of that pipe to be closed as part of unpack(). Normally, this works fine. After start_command forks, it closes the parent copy of the descriptor. Then once the child exits (whether it was successful or not), that closes the only remaining writer. However, there is one code-path in unpack() that does not handle this. Before we decide which of unpack-objects or index-pack to use, we read the pack header ourselves to see how many objects it contains. If there is an error here, we exit without running either sub-command, the pipe descriptor remains open, and we are in a deadlock, waiting for the sideband thread to die (which is in turn waiting for us to close the pipe). We can fix this by making sure that unpack() always closes the pipe before returning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19Merge branch 'jn/add-2.0-u-A-sans-pathspec' (early part)Libravatar Junio C Hamano1-40/+94
In Git 2.0, "git add -u" and "git add -A" without any pathspec will update the index for all paths, including those outside the current directory, making it more consistent with "commit -a". To help the migration pain, a warning is issued when the differences between the current behaviour and the upcoming behaviour matters, i.e. when the user has local changes outside the current directory. * 'jn/add-2.0-u-A-sans-pathspec' (early part): add -A: only show pathless 'add -A' warning when changes exist outside cwd add -u: only show pathless 'add -u' warning when changes exist outside cwd add: make warn_pathless_add() a no-op after first call add: add a blank line at the end of pathless 'add [-u|-A]' warning add: make pathless 'add [-u|-A]' warning a file-global function
2013-04-19Merge branch 'ap/strbuf-humanize'Libravatar Junio C Hamano1-8/+36
Teach "--human-readable" aka "-H" option to "git count-objects" to show various large numbers in Ki/Mi/GiB scaled as necessary. * ap/strbuf-humanize: count-objects: add -H option to humanize sizes strbuf: create strbuf_humanise_bytes() to show byte sizes
2013-04-19Merge branch 'fc/branch-upstream-color'Libravatar Junio C Hamano1-8/+28
Add more colors to "git branch -vv" output. * fc/branch-upstream-color: branch: colour upstream branches
2013-04-18pretty: save commit encoding from logmsg_reencode if the caller needs itLibravatar Nguyễn Thái Ngọc Duy2-2/+2
The commit encoding is parsed by logmsg_reencode, there's no need for the caller to re-parse it again. The reencoded message now has the new encoding, not the original one. The caller would need to read commit object again before parsing. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-13/+13
The resolution of some corner cases by "git merge-tree" were inconsistent between top-of-the-tree and in a subdirectory. * jk/merge-tree-added-identically: merge-tree: don't print entries that match "local"
2013-04-18Merge branch 'fc/send-email-annotate'Libravatar Junio C Hamano1-81/+85
Allows format-patch --cover-letter to be configurable; the most notable is the "auto" mode to create cover-letter only for multi patch series. * fc/send-email-annotate: rebase-am: explicitly disable cover-letter format-patch: trivial cleanups format-patch: add format.coverLetter configuration variable log: update to OPT_BOOL format-patch: refactor branch name calculation format-patch: improve head calculation for cover-letter send-email: make annotate configurable
2013-04-18Merge branch 'kb/co-orphan-suggestion-short-sha1'Libravatar Junio C Hamano1-1/+1
Update the informational message when "git checkout" leaves the detached head state. * kb/co-orphan-suggestion-short-sha1: checkout: abbreviate hash in suggest_reattach
2013-04-17git add: rework the logic to warn "git add <pathspec>..." default changeLibravatar Junio C Hamano1-26/+38
The earlier logic to warn against "git add subdir" that is run without "-A" or "--no-all" was only to check any <pathspec> given exactly spells a directory name that (still) exists on the filesystem. This had number of problems: * "git add '*dir'" (note that the wildcard is hidden from the shell) would not trigger the warning. * "git add '*.py'" would behave differently between the current version of Git and Git 2.0 for the same reason as "subdir", but would not trigger the warning. * "git add dir" for a submodule "dir" would just update the index entry for the submodule "dir" without ever recursing into it, and use of "-A" or "--no-all" would matter. But the logic only checks the directory-ness of "dir" and gives an unnecessary warning. Rework the logic to detect the case where the behaviour will be different in Git 2.0, and issue a warning only when it matters. Even with the code before this warning, "git add subdir" will have to traverse the directory in order to find _new_ files the index does not know about _anyway_, so we can do this check without adding an extra pass to find if <pathspec> matches any removed file. This essentially updates the "add_files_to_cache()" public API to "update_files_in_cache()" API that is internal to "git add", because with the "--all" option, the function is no longer about "adding" paths to the cache, but is also used to remove them. There are other callers of the former from "checkout" (used when "checkout -m" prepares the temporary tree that represents the local modifications to be merged) and "commit" ("commit --include" that picks up local changes in addition to what is in the index). Since ADD_CACHE_IGNORE_ERRORS (aka "--no-all") is not used by either of them, once dust settles after Git 2.0 and the warning becomes unnecessary, we may want to unify these two functions again. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17blame: handle broken commit headers gracefullyLibravatar René Scharfe1-3/+8
split_ident_line() can leave us with the pointers date_begin, date_end, tz_begin and tz_end all set to NULL. Check them before use and supply the same fallback values as in the case of a negative return code from split_ident_line(). The "(unknown)" is not actually shown in the output, though, because it will be converted to a number (zero) eventually. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17cat-file: print tags raw for "cat-file -p"Libravatar Jeff King1-71/+0
When "cat-file -p" prints commits, it shows them in their raw format, since git's format is already human-readable. For tags, however, we print the whole thing raw except for one thing: we convert the timestamp on the tagger line into a human-readable date. This dates all the way back to a0f15fa (Pretty-print tagger dates, 2006-03-01). At that time there was no other way to pretty-print a tag. These days, however, neither of those matters much. The normal way to pretty-print a tag is with "git show", which is much more flexible than "cat-file -p". Commit a0f15fa also built "verify-tag --verbose" (and subsequently "tag -v") around the "cat-file -p" output. However, that behavior was lost in commit 62e09ce (Make git tag a builtin, 2007-07-20), and we went back to printing the raw tag contents. Nobody seems to have noticed the bug since then (and it is arguably a saner behavior anyway, as it shows the actual bytes for which we verified the signature). Let's drop the tagger-date formatting for "cat-file -p". It makes us more consistent with cat-file's commit pretty-printer, and as a bonus, we can drop the hand-rolled tag parsing code in cat-file (which happened to behave inconsistently with the tag pretty-printing code elsewhere). This is a change of output format, so it's possible that some callers could considered this a regression. However, the original behavior was arguably a bug (due to the inconsistency with commits), likely nobody was relying on it (even we do not use it ourselves these days), and anyone relying on the "-p" pretty-printer should be able to expect a change in the output format (i.e., while "cat-file" is plumbing, the output format of "-p" was never guaranteed to be stable). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15Merge branch 'rt/commentchar-fmt-merge-msg'Libravatar Junio C Hamano1-7/+11
The new core.commentchar configuration was not applied to a few places. * rt/commentchar-fmt-merge-msg: fmt-merge-msg: use core.commentchar in tag signatures completely fmt-merge-msg: respect core.commentchar in people credits
2013-04-15Merge branch 'jk/show-branch-strbuf'Libravatar Junio C Hamano1-9/+8
"git show-branch" was not prepared to show a very long run of ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly. * jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer
2013-04-15dir.c: git-status --ignored: don't scan the work tree twiceLibravatar Karsten Blees1-1/+0
'git-status --ignored' still scans the work tree twice to collect untracked and ignored files, respectively. fill_directory / read_directory already supports collecting untracked and ignored files in a single directory scan. However, the DIR_COLLECT_IGNORED flag to enable this has some git-add specific side-effects (e.g. it doesn't recurse into ignored directories, so listing ignored files with --untracked=all doesn't work). The DIR_SHOW_IGNORED flag doesn't list untracked files and returns ignored files in dir_struct.entries[] (instead of dir_struct.ignored[] as DIR_COLLECT_IGNORED). DIR_SHOW_IGNORED is used all throughout git. We don't want to break the existing API, so lets introduce a new flag DIR_SHOW_IGNORED_TOO that lists untracked as well as ignored files similar to DIR_COLLECT_FILES, but will recurse into sub-directories based on the other flags as DIR_SHOW_IGNORED does. In dir.c::read_directory_recursive, add ignored files to either dir_struct.entries[] or dir_struct.ignored[] based on the flags. Also move the DIR_COLLECT_IGNORED case here so that filling result lists is in a common place. In wt-status.c::wt_status_collect_untracked, use the new flag and read results from dir_struct.ignored[]. Remove the extra fill_directory call. builtin/check-ignore.c doesn't call fill_directory, setting the git-add specific DIR_COLLECT_IGNORED flag has no effect here. Remove for clarity. Update API documentation to reflect the changes. Performance: with this patch, 'git-status --ignored' is typically as fast as 'git-status'. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>