path: root/builtin/rm.c
AgeCommit message (Collapse)Author
2015-05-20use file_exists() to check if a file exists in the worktreeRené Scharfe
Call file_exists() instead of open-coding it. That's shorter, simpler and the intent becomes clearer. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
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 <> Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2014-09-02grammofix in user-facing messagesAlex Henrie
Signed-off-by: Alex Henrie <> Acked-by: Johan Herland <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2014-02-27Merge branch 'nd/submodule-pathspec-ending-with-slash'Junio C Hamano
Allow "git cmd path/", when the 'path' is where a submodule is bound to the top-level working tree, to match 'path', despite the extra and unnecessary trailing slash. * nd/submodule-pathspec-ending-with-slash: clean: use cache_name_is_other() clean: replace match_pathspec() with dir_path_match() pathspec: pass directory indicator to match_pathspec_item() match_pathspec: match pathspec "foo/" against directory "foo" dir.c: prepare match_pathspec_item for taking more flags pathspec: rename match_pathspec_depth() to match_pathspec() pathspec: convert some match_pathspec_depth() to dir_path_match() pathspec: convert some match_pathspec_depth() to ce_path_match()
2014-02-24pathspec: convert some match_pathspec_depth() to ce_path_match()Nguyễn Thái Ngọc Duy
This helps reduce the number of match_pathspec_depth() call sites and show how match_pathspec_depth() is used. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2013-11-18read-cache.c: fix memory leaks caused by removed cache entriesKarsten Blees
When cache_entry structs are removed from index_state.cache, they are not properly freed. Freeing those entries wasn't possible before because we couldn't remove them from index_state.name_hash. Now that we _do_ remove the entries from name_hash, we can also free them. Add 'free(cache_entry)' to all call sites of name-hash.c::remove_name_hash in read-cache.c (we could free() directly in remove_name_hash(), but name-hash.c isn't concerned with cache_entry allocation at all). Accessing a cache_entry after removing it from the index is now no longer allowed, as the memory has been freed. The following functions need minor fixes (typically by copying ce->name before use): - builtin/rm.c::cmd_rm - builtin/update-index.c::do_reupdate - read-cache.c::read_index_unmerged - resolve-undo.c::unmerge_index_entry_at Signed-off-by: Karsten Blees <> Signed-off-by: Junio C Hamano <>
2013-09-13rm: re-use parse_pathspec's trailing-slash removalJohn Keeping
Instead of re-implementing the "remove trailing slashes" loop in builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to parse_pathspec. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
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-04Merge branch 'sb/parseopt-boolean-removal'Junio C Hamano
Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary. * sb/parseopt-boolean-removal: revert: use the OPT_CMDMODE for parsing, reducing code checkout-index: fix negations of even numbers of -n config parsing options: allow one flag multiple times hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP branch, commit, name-rev: ease up boolean conditions checkout: remove superfluous local variable log, format-patch: parsing uses OPT__QUIET Replace deprecated OPT_BOOLEAN by OPT_BOOL Remove deprecated OPTION_BOOLEAN for parsing arguments
2013-08-09rm: remove unneeded null pointer checkStefan Beller
As of 7612a1efdb (2006-06-09 git-rm: honor -n flag.) the variable 'pathspec' seems to be assumed to be never NULL after calling get_pathspec There was a NULL pointer check after the seen = NULL assignment, which was removed by that commit. So if pathspec would be NULL now, we'd segfault in the line accessing the pathspec: for (i = 0; pathspec[i] ; i++) A few lines later, 'pathspec' still cannot be NULL, but that check was overlooked, hence removing it now. As the null pointer check was removed, it makes no sense to assign NULL to seen and 3 lines later another value as there are no conditions in between. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-08-06rm: delete .gitmodules entry of submodules removed from the work treeJens Lehmann
Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-08-01Merge branch 'jc/rm-submodule-error-message'Junio C Hamano
Consolidate two messages phrased subtly differently without a good reason. * jc/rm-submodule-error-message: builtin/rm.c: consolidate error reporting for removing submodules
2013-07-26builtin/rm.c: consolidate error reporting for removing submodulesJunio C Hamano
We have two (not identical) copies of error reporting when attempting to remove submodules that have their repositories embedded within them. Add a helper function so that we do not have to repeat similar error messages with subtly different wording without a good reason. Noticed by Jiang Xin. Signed-off-by: Junio C Hamano <>
2013-07-23rm: do not set a variable twice without intermediate reading.Stefan Beller
Just the next line assigns a non-null value to seen. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2013-07-15rm: convert to use parse_pathspecNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2013-07-09Convert "struct cache_entry *" to "const ..." wherever possibleNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2013-06-12rm: introduce advice.rmHints to shorten messagesMathieu Lienard--Mayor
Introduce advice.rmHints to choose whether to display advice or not when git rm fails. Defaults to true, in order to preserve current behavior. As an example, the message: error: 'foo.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) would look like, with advice.rmHints=false: error: 'foo.txt' has changes staged in the index Signed-off-by: Mathieu Lienard--Mayor <> Signed-off-by: Jorge Juan Garcia Garcia <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2013-06-12rm: better error message on failure for multiple filesMathieu Lienard--Mayor
When 'git rm' fails, it now displays a single message with the list of files involved, instead of displaying a list of messages with one file each. As an example, the old message: error: 'foo.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) error: 'bar.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) would now be displayed as: error: the following files have changes staged in the index: foo.txt bar.txt (use --cached to keep the file, or -f to force removal) Signed-off-by: Mathieu Lienard--Mayor <> Signed-off-by: Jorge Juan Garcia Garcia <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2013-04-04rm: do not complain about d/f conflicts during deletionJeff King
If we used to have an index entry "d/f", but "d" has been replaced by a non-directory entry, the user may still want to run "git rm" to delete the stale index entry. They could use "git rm --cached" to just touch the index, but "git rm" should also work: we explicitly try to handle the case that the file has already been removed from the working tree. However, because unlinking "d/f" in this case will not yield ENOENT, but rather ENOTDIR, we do not notice that the file is already gone. Instead, we report it as an error. The simple solution is to treat ENOTDIR in this case exactly like ENOENT; all we want to know is whether the file is already gone, and if a leading path is no longer a directory, then by definition the sub-path is gone. Reported-by: jpinheiro <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-11-29Merge branch 'jl/submodule-rm'Junio C Hamano
Finishing touches to "git rm $submodule" that removes the working tree of a submodule. * jl/submodule-rm: Teach rm to remove submodules when given with a trailing '/'
2012-11-24Teach rm to remove submodules when given with a trailing '/'Jens Lehmann
Doing a "git rm submod/" on a submodule results in an error: fatal: pathspec 'submod/' did not match any files This is really inconvenient as e.g. using TAB completion in a shell on a submodule automatically adds the trailing '/' when it completes the path of the submodule directory. The user has then to remove the '/' herself to make a "git rm" succeed. Doing a "git rm -r somedir/" is working fine, so there is no reason why that shouldn't work for submodules too. Teach git rm to not error out when a '/' is appended to the path of a submodule. Achieve this by chopping off trailing slashes from the path names given if they represent directories. Add tests to make sure that logic only applies to directories and not to files. Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2012-10-29Merge branch 'jl/submodule-rm'Jeff King
"git rm submodule" cannot blindly remove a submodule directory as its working tree may have local changes, and worse yet, it may even have its repository embedded in it. Teach it some special cases where it is safe to remove a submodule, specifically, when there is no local changes in the submodule working tree, and its repository is not embedded in its working tree but is elsewhere and uses the gitfile mechanism to point at it. * jl/submodule-rm: submodule: teach rm to remove submodules unless they contain a git directory
2012-09-29submodule: teach rm to remove submodules unless they contain a git directoryJens Lehmann
Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2012-08-20i18n: rm: mark parseopt strings for translationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-03-10i18n: git-rm basic messagesÆvar Arnfjörð Bjarmason
Make the basic git-mv messages translatable, but skip things like "rm '%s'\n" and "git rm '%s'\n" for now. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2010-12-19builtin/rm.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.Thiago Farina
Signed-off-by: Thiago Farina <> Signed-off-by: Junio C Hamano <>
2010-11-15Describe various forms of "be quiet" using OPT__QUIETJonathan Nieder
Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-11-15add OPT__FORCERené Scharfe
Add OPT__FORCE as a helper macro in the same spirit as OPT__VERBOSE to simplify defining -f/--force options. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2010-11-15add description parameter to OPT__QUIETRené Scharfe
Allows better help text to be defined than "be quiet". Also make use of the macro in a place that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2010-11-15add description parameter to OPT__DRY_RUNRené Scharfe
Allows better help text to be defined than "dry run". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>