summaryrefslogtreecommitdiff
path: root/builtin/add.c
AgeCommit message (Collapse)Author
2015-10-30Merge branch 'jc/add-u-A-default-to-top'Junio C Hamano
"git --literal-pathspecs add -u/-A" without any command line argument misbehaved ever since Git 2.0. * jc/add-u-A-default-to-top: add: simplify -u/-A without pathspec
2015-10-25add: simplify -u/-A without pathspecJunio C Hamano
Since Git 2.0, "add -u" and "add -A" run from a subdirectory without any pathspec mean "everything in the working tree" (before 2.0, they were limited to the current directory). The limiting to the current directory was implemented by inserting "." to the command line when the end user did not give us any pathspec. At 2.0, we updated the code to insert ":/" (instead of '.') to consider everything from the top-level, by using a pathspec magic "top". The call to parse_pathspec() using the command line arguments is, however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add: convert to use parse_pathspec, 2013-07-14), which predates Git 2.0. In retrospect, there was no need to turn "adding . to limit to the directory" into "adding :/ to unlimit to everywhere" in Git 2.0; instead we could just have done "if there is no pathspec on the command line, just let it be". The parse_pathspec() then would give us a pathspec that matches everything and all is well. Incidentally such a simplification also fixes a corner case bug that stems from the fact that ":/" does not necessarily mean any magic. A user would say "git --literal-pathspecs add -u :/" from the command line when she has a directory ':' and wants to add everything in it (and she knows that her :/ will be taken as 'everything under the sun' magic pathspec unless she disables the magic with --literal-pathspecs). The internal use of ':/' would behave the same way as such an explicitly given ":/" when run with "--literal-pathspecs", and will not add everything under the sun as the code originally intended. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-12Merge branch 'sb/remove-unused-var-from-builtin-add'Junio C Hamano
* sb/remove-unused-var-from-builtin-add: add: remove dead code
2015-07-31add: remove dead codeStefan Beller
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25Merge branch 'nd/diff-i-t-a'Junio C Hamano
* nd/diff-i-t-a: Revert "diff-lib.c: adjust position of i-t-a entries in diff"
2015-06-23Revert "diff-lib.c: adjust position of i-t-a entries in diff"Junio C Hamano
This reverts commit d95d728aba06a34394d15466045cbdabdada58a2. It turns out that many other commands that need to interact with the result of running diff-files and diff-index, e.g. "git apply", "git rm", etc., need to be adjusted to the new world order it brings in. For example, it would break this sequence to correct a whitespace breakage in the parts you changed: git add -N file git diff --cached file | git apply --cached --whitespace=fix git checkout file In the old world order, "diff" showed a patch to modify an existing empty file by adding its full contents, and "apply" updated the index by modifying the existing empty blob (which is what an Intent-to-Add entry records in the index) with that patch. In the new world order, "diff" shows a patch to create a new file with its full contents, but because "apply" thinks that the i-t-a entry already exists in the index, it refused to accept a creation. Adjusting "apply" to this new world order is easy, but we need to assess the extent of the damage to the rest of the system the new world order brought in before going forward and adjust them all, after which we can resurrect the commit being reverted here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Merge branch 'jk/add-e-kill-editor'Junio C Hamano
"git add -e" did not allow the user to abort the operation by killing the editor. * jk/add-e-kill-editor: add: check return value of launch_editor
2015-05-13add: check return value of launch_editorJeff King
When running "add -e", if launching the editor fails, we do not notice and continue as if the output is what the user asked for. The likely case is that the editor did not touch the contents at all, and we end up adding everything. Reported-by: Russ Cox <rsc@golang.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23diff-lib.c: adjust position of i-t-a entries in diffNguyễn Thái Ngọc Duy
Entries added by "git add -N" are reminder for the user so that they don't forget to add them before committing. These entries appear in the index even though they are not real. Their presence in the index leads to a confusing "git status" like this: On branch master Changes to be committed: new file: foo Changes not staged for commit: modified: foo If you do a "git commit", "foo" will not be included even though "status" reports it as "to be committed". This patch changes the output to become On branch master Changes not staged for commit: new file: foo no changes added to commit The two hunks in diff-lib.c adjust "diff-index" and "diff-files" so that i-t-a entries appear as new files in diff-files and nothing in diff-index. Due to this change, diff-files may start to report "new files" for the first time. "add -u" needs to be told about this or it will die in denial, screaming "new files can't exist! Reality is wrong." Luckily, it's the only one among run_diff_files() callers that needs fixing. Now in the new world order, a hierarchy in the index that contain i-t-a paths is written out as a tree object as if these i-t-a entries do not exist, and comparing the index with such a tree object that would result from writing out the hierarchy will result in no difference. Update a test in t2203 that expected the i-t-a entries to appear as "added to the index" in the comparison to instead expect no output. An earlier change eec3e7e4 (cache-tree: invalidate i-t-a paths after generating trees, 2012-12-16) becomes an unnecessary pessimization in the new world order---a cache-tree in the index that corresponds to a hierarchy with i-t-a paths can now be marked as valid and record the object name of the tree that results from writing a tree object out of that hierarchy, as it will compare equal to that tree. Reverting the commit is left for the future, though, as it is purely a performance issue and no longer affects correctness. Helped-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14standardize usage info string formatAlex Henrie
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21add: ignore only ignored filesMichael J Gruber
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when "git add foo.*" is subject to shell expansion and some of the expanded files are ignored. "git add --ignore-errors" is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error "file is ignored" as outlined above. This is unexpected. Change "git add foo bar" to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without "--ignore-errors") in which we act for more severe indexing errors when "--ignore-errors" is specified. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01lockfile.h: extract new header file for the functions in lockfile.cMichael Haggerty
Move the interface declaration for the functions in lockfile.c from cache.h to a new file, lockfile.h. Add #includes where necessary (and remove some redundant includes of cache.h by files that already include builtin.h). Move the documentation of the lock_file state diagram from lockfile.c to the new header file. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-20run-command: introduce CHILD_PROCESS_INITRené Scharfe
Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: new API write_locked_index instead of write_index/write_cacheNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-28Merge branch 'fr/add-interactive-argv-array'Junio C Hamano
* fr/add-interactive-argv-array: add: use struct argv_array in run_add_interactive()
2014-03-18add: use struct argv_array in run_add_interactive()Fabian Ruch
run_add_interactive() in builtin/add.c manually computes array bounds and allocates a static args array to build the add--interactive command line, which is error-prone. Use the argv-array helper functions instead. Signed-off-by: Fabian Ruch <bafain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-07Merge branch 'jc/add-2.0-ignore-removal'Junio C Hamano
"git add <pathspec>" is the same as "git add -A <pathspec>" now, i.e. it does not ignore removals from the directory specified.
2014-03-07Merge branch 'jn/add-2.0-u-A-sans-pathspec'Junio C Hamano
"git add -u" and "git add -A" without any pathspec is a tree-wide operation now, even when they are run in a subdirectory of the working tree.
2014-02-24pathspec: convert some match_pathspec_depth() to dir_path_match()Nguyễn Thái Ngọc Duy
This helps reduce the number of match_pathspec_depth() call sites and show how m_p_d() is used. And it usage is: - match against an index entry (ce_path_match or match_pathspec_depth in ls-files) - match against a dir_entry from read_directory (dir_path_match and match_pathspec_depth in clean.c, which will be converted later) - resolve-undo (rerere.c and ls-files.c) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-10Merge branch 'nd/add-empty-fix'Junio C Hamano
"git add -A" (no other arguments) in a totally empty working tree used to emit an error. * nd/add-empty-fix: add: don't complain when adding empty project root
2013-12-26add: don't complain when adding empty project rootNguyễn Thái Ngọc Duy
This behavior was added in 07d7bed (add: don't complain when adding empty project root - 2009-04-28) then broken by 84b8b5d (remove match_pathspec() in favor of match_pathspec_depth() - 2013-07-14). Reinstate it. Noticed-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-06Support pathspec magic :(exclude) and its short form :!Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17Merge branch 'fc/trivial'Junio C Hamano
* fc/trivial: pull: use $curr_branch_short more add: trivial style cleanup reset: trivial style cleanup branch: trivial style fix reset: trivial refactoring
2013-09-09Merge branch 'nd/magic-pathspec'Junio C Hamano
Use "struct pathspec" interface in more places, instead of array of characters, the latter of which cannot express magic pathspecs (e.g. ":(icase)makefile" that matches both Makefile and makefile). * nd/magic-pathspec: add: lift the pathspec magic restriction on "add -p" pathspec: catch prepending :(prefix) on pathspec with short magic
2013-09-09Merge branch 'jl/submodule-mv'Junio C Hamano
"git mv A B" when moving a submodule A does "the right thing", inclusing relocating its working tree and adjusting the paths in the .gitmodules file. * jl/submodule-mv: (53 commits) rm: delete .gitmodules entry of submodules removed from the work tree mv: update the path entry in .gitmodules for moved submodules submodule.c: add .gitmodules staging helper functions mv: move submodules using a gitfile mv: move submodules together with their work trees rm: do not set a variable twice without intermediate reading. t6131 - skip tests if on case-insensitive file system parse_pathspec: accept :(icase)path syntax pathspec: support :(glob) syntax pathspec: make --literal-pathspecs disable pathspec magic pathspec: support :(literal) syntax for noglob pathspec kill limit_pathspec_to_literal() as it's only used by parse_pathspec() parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN parse_pathspec: make sure the prefix part is wildcard-free rename field "raw" to "_raw" in struct pathspec tree-diff: remove the use of pathspec's raw[] in follow-rename codepath remove match_pathspec() in favor of match_pathspec_depth() remove init_pathspec() in favor of parse_pathspec() remove diff_tree_{setup,release}_paths convert common_prefix() to use struct pathspec ...
2013-09-05add: lift the pathspec magic restriction on "add -p"Nguyễn Thái Ngọc Duy
Since 480ca64 (convert run_add_interactive to use struct pathspec - 2013-07-14), we have unconditionally passed :(prefix)xxx to add-interactive.perl. It implies that all commands add-interactive.perl calls must be aware of pathspec magic, or :(prefix) is barfed. The restriction to :/ only becomes unnecessary. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-31add: trivial style cleanupFelipe Contreras
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'mm/color-auto-default'Junio C Hamano
A finishing touch to fix breakage to "add -e" caused by defaulting ui.color to "auto". * mm/color-auto-default: git add -e: Explicitly specify that patch should have no color
2013-07-19git add -e: Explicitly specify that patch should have no colorAndrew Wong
After 4c7f1819 (make color.ui default to 'auto', 2013-06-10), the patch file to be edited during 'git add -e' receives all the color codes. This is because diffopt.use_color defaults to -1, which causes want_color to now return 'auto'. By explicitly setting use_color to 0, we can ensure the diff output has no color codes in it. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15parse_pathspec: accept :(icase)path syntaxNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15pathspec: support :(glob) syntaxNguyễn Thái Ngọc Duy
:(glob)path differs from plain pathspec that it uses wildmatch with WM_PATHNAME while the other uses fnmatch without FNM_PATHNAME. The difference lies in how '*' (and '**') is processed. With the introduction of :(glob) and :(literal) and their global options --[no]glob-pathspecs, the user can: - make everything literal by default via --noglob-pathspecs --literal-pathspecs cannot be used for this purpose as it disables _all_ pathspec magic. - individually turn on globbing with :(glob) - make everything globbing by default via --glob-pathspecs - individually turn off globbing with :(literal) The implication behind this is, there is no way to gain the default matching behavior (i.e. fnmatch without FNM_PATHNAME). You either get new globbing or literal. The old fnmatch behavior is considered deprecated and discouraged to use. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15pathspec: support :(literal) syntax for noglob pathspecNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15remove match_pathspec() in favor of match_pathspec_depth()Nguyễn Thái Ngọc Duy
match_pathspec_depth was created to replace match_pathspec (see 61cf282 (pathspec: add match_pathspec_depth() - 2010-12-15). It took more than two years, but the replacement finally happens :-) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15convert add_files_to_cache to take struct pathspecNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15convert {read,fill}_directory to take struct pathspecNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15convert refresh_index to take struct pathspecNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15convert run_add_interactive to use struct pathspecNguyễn Thái Ngọc Duy
This passes the pathspec, more or less unmodified, to git-add--interactive. The command itself does not process pathspec. It simply passes the pathspec to other builtin commands. So if all those commands support pathspec, we're good. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15add: convert to use parse_pathspecNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-26git add: -u/-A now affects the entire working treeJunio C Hamano
As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without pathspec, 2013-01-28), in Git 2.0, "git add -u/-A" that is run without pathspec in a subdirectory updates all updated paths in the entire working tree, not just the current directory and its subdirectories. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-26Merge branch 'jc/add-ignore-removal'Junio C Hamano
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'Junio C Hamano
* 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 pathsJunio C Hamano
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-23Merge branch 'kb/status-ignored-optim-2'Junio C Hamano
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-23git add <pathspec>... defaults to "-A"Junio C Hamano
Make "git add <pathspec>..." notice paths that have been removed from the working tree, i.e. the same as "git add -A <pathspec>...". Given that "git add <pathspec>" is to update the index with the state of the named part of the working tree as a whole, it makes it more intuitive, and also makes it possible to simplify the advice we give while marking the paths the user finished resolving conflicts with. We used to say "to record removal as a resolution, remove the path from the working tree and say 'git rm'; for all other cases, edit the path in the working tree and say 'git add'", but we can now say "update the path in the working tree and say 'git add'" instead. As promised, this merges the temporary update_files_in_cache() helper function back to add_files_to_cache() function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22git add: rephrase -A/--no-all warningJunio C Hamano
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-allJunio C Hamano
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 'jc/add-2.0-delete-default' (early part)Junio C Hamano
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-22git add: rephrase the "removal will cease to be ignored" warningJunio C Hamano
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-18git add: rework the logic to warn "git add <pathspec>..." default changeJunio C Hamano
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-15dir.c: replace is_path_excluded with now equivalent is_excluded APIKarsten Blees
Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>