aboutsummaryrefslogtreecommitdiff
path: root/builtin-rm.c
Commit message (Collapse)AuthorAge
* git rm: refresh index before up-to-date checkJohannes Schindelin2008-10-08
| | | | | | | | Since "git rm" is supposed to be porcelain, we should convince it to be user friendly by refreshing the index itself. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Use remove_path from dir.c instead of own implementationAlex Riesen2008-09-29
| | | | | | | | Besides, it fixes a memleak (builtin-rm.c) and accidental change of the input const argument (builtin-merge-recursive.c). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Start conforming code to "git subcmd" style part 3Heikki Orsila2008-09-15
| | | | | | | | User notifications are presented as 'git cmd', and code comments are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'. Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'git foo' program identifies itself without dash in die() messagesJunio C Hamano2008-08-31
| | | | | | | | | | This is a mechanical conversion of all '*.c' files with: s/((?:die|error|warning)\("git)-(\S+:)/$1 $2/; The result was manually inspected and no false positive was found. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-rm: Add a --force flagPieter de Bie2008-08-08
| | | | | | | | This adds a --force flag to git-rm, making it somewhat easier for subversion people to switch. Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-07-19
|\ | | | | | | | | | | | | | | | | * maint: GIT 1.5.6.4 builtin-rm: fix index lock file path http-fetch: do not SEGV after fetching a bad pack idx file rev-list: honor --quiet option api-run-command.txt: typofix
| * builtin-rm: fix index lock file pathOlivier Marin2008-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When hold_locked_index() is called with a relative git_dir and you are outside the work tree, the lock file become relative to the current directory. So when later setup_work_tree() change the current directory it breaks lock file path and commit_locked_index() fails. This patch move index locking code after setup_work_tree() call to make lock file relative to the working tree as it should be and add a test case. Noticed by Nick Andrew. Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Make usage strings dash-lessStephan Beyer2008-07-13
|/ | | | | | | | | | | | | | | When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Provide git_config with a callback-data parameterJohannes Schindelin2008-05-14
| | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Improve use of lockfile APIBrandon Casey2008-01-16
| | | | | | | Remove remaining double close(2)'s. i.e. close() before commit_locked_index() or commit_lock_file(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Don't always require working tree for git-rmMike Hommey2007-11-05
| | | | | | | | | | This allows to do git rm --cached -r directory, instead of git ls-files -z directory | git update-index --remove -z --stdin. This can be particularly useful for git-filter-branch users. Signed-off-by: Mike Hommey <mh@glandium.org> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make builtin-rm.c use parse_options.Pierre Habouzit2007-10-29
| | | | | Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Simplify cache APIJunio C Hamano2007-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Earlier, add_file_to_index() invalidated the path in the cache-tree but remove_file_from_cache() did not, and the user of the latter needed to invalidate the entry himself. This led to a few bugs due to missed invalidate calls already. This patch makes the management of cache-tree less error prone by making more invalidate calls from lower level cache API functions. The rules are: - If you are going to write the index, you should either maintain cache_tree correctly. - If you cannot, alternatively you can remove the entire cache_tree by calling cache_tree_free() before you call write_cache(). - When you modify the index, cache_tree_invalidate_path() should be called with the path you are modifying, to discard the entry from the cache-tree structure. - The following cache API functions exported from read-cache.c (and the macro whose names have "cache" instead of "index") automatically call cache_tree_invalidate_path() for you: - remove_file_from_index(); - add_file_to_index(); - add_index_entry(); You can modify the index bypassing the above API functions (e.g. find an existing cache entry from the index and modify it in place). You need to call cache_tree_invalidate_path() yourself in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* More permissive "git-rm --cached" behavior without -f.Matthieu Moy2007-07-13
| | | | | | | | | | | | | | | | In the previous behavior, "git-rm --cached" (without -f) had the same restriction as "git-rm". This forced the user to use the -f flag in situations which weren't actually dangerous, like: $ git add foo # oops, I didn't want this $ git rm --cached foo # back to initial situation Previously, the index had to match the file *and* the HEAD. With --cached, the index must now match the file *or* the HEAD. The behavior without --cached is unchanged, but provides better error messages. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add --ignore-unmatch option to exit with zero status when no files are removed.Steven Grimm2007-04-17
| | | | | Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm: Trivial fix for a comment typo.Steven Grimm2007-04-16
| | | | | Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --quiet option to suppress output of "rm" commands for removed files.Steven Grimm2007-04-16
| | | | | Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.Junio C Hamano2007-04-03
| | | | | | | | | | | | | | | | | | | | | When defined, this allows plumbing commands that update the index (add, apply, checkout-index, merge-recursive, mv, read-tree, rm, update-index, and write-tree) to write their resulting index to an alternative index file while holding a lock to the original index file. With this, git-commit that jumps the index does not have to make an extra copy of the index file, and more importantly, it can do the update while holding the lock on the index. However, I think the interface to let an environment variable specify the output is a mistake, as shown in the documentation. If a curious user has the environment variable set to something other than the file GIT_INDEX_FILE points at, almost everything will break. This should instead be a command line parameter to tell these plumbing commands to write the result in the named file, to prevent stupid mistakes. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm: don't remove newly added file without -fJeff King2007-03-27
| | | | | | | | | | | | | | | | | | Given this set of commands: $ echo "newly added file" >new $ git add new $ git rm new the file "new" was previously removed from the working directory and the index. Because it was not in HEAD, it is available only by searching for unreachable objects. Instead, we now err on the safe side and refuse to remove a file which is not referenced by HEAD. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm documentation: remove broken behaviour from the example.Junio C Hamano2007-01-16
| | | | | | | The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm: do not fail on already removed file.Junio C Hamano2007-01-11
| | | | | | | | | | | Often the user would do "/bin/rm foo" before telling git, but then want to tell git about it. "git rm foo" however would fail because it cannot unlink(2) foo. Treat ENOENT error return from unlink(2) as if a successful removal happened. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm: update to saner semanticsJunio C Hamano2006-12-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates the "git rm" command with saner semantics suggested on the list earlier with: Message-ID: <Pine.LNX.4.64.0612020919400.3476@woody.osdl.org> Message-ID: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org> The command still validates that the given paths all talk about sensible paths to avoid mistakes (e.g. "git rm fiel" when file "fiel" does not exist would error out -- user meant to remove "file"), and it has further safety checks described next. The biggest difference is that the paths are removed from both index and from the working tree (if you have an exotic need to remove paths only from the index, you can use the --cached option). The command refuses to remove if the copy on the working tree does not match the index, or if the index and the HEAD does not match. You can defeat this check with -f option. This safety check has two exceptions: if the working tree file does not exist to begin with, that technically does not match the index but it is allowed. This is to allow this CVS style command sequence: rm <path> && git rm <path> Also if the index is unmerged at the <path>, you can use "git rm <path>" to declare that the result of the merge loses that path, and the above safety check does not trigger; requiring the file to match the index in this case forces the user to do "git update-index file && git rm file", which is just crazy. To recursively remove all contents from a directory, you need to pass -r option, not just the directory name as the <path>. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Replace uses of strdup with xstrdup.Shawn Pearce2006-09-02
| | | | | | | | | | | | | | | | Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Better error message when we are unable to lock the index fileJunio C Hamano2006-08-12
| | | | | | | | | | | | | | | | | Most of the callers except the one in refs.c use the function to update the index file. Among the index writers, everybody except write-tree dies if they cannot open it for writing. This gives the function an extra argument, to tell it to die when it cannot create a new file as the lockfile. The only caller that does not have to die is write-tree, because updating the index for the cache-tree part is optional and not being able to do so does not affect the correctness. I think we do not have to be so careful and make the failure into die() the same way as other callers, but that would be a different patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Further clean-up: usage() vs die()Junio C Hamano2006-08-03
| | | | | | | | This hopefully finishes the clean-up Ramsay started with recent commit 15e593e4d37d1d350fef20ab666d58f6881c7f5f and commit 8cdf33643dc0b21d9ea922a3fdd7f64226c421aa. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Replace some calls to die(usage_str) with usage(usage_str).Ramsay Allan Jones2006-08-03
| | | | | | | | | The only change in behaviour should be having a "usage: " prefix on the output string rather than "fatal: ", and an exit code of 129 rather than 128. Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Call setup_git_directory() much earlierLinus Torvalds2006-07-29
| | | | | | | | | This changes the calling convention of built-in commands and passes the "prefix" (i.e. pathname of $PWD relative to the project root level) down to them. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Substitute xmalloc()+memset(0) with xcalloc().Peter Eriksen2006-07-25
| | | | | Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix more typos, primarily in the codePavel Roskin2006-07-10
| | | | | | | | | The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Close the index file between writing and committingJohannes Schindelin2006-07-08
| | | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm: honor -n flag.Junio C Hamano2006-06-08
| | | | | | | | | Even when invoked with -n flag, git-rm removed the matching paths anyway. Also includes the missing check spotted by SungHyun Nam, which caused it to segfault. Now we refuse to run without any paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make index file locking code reusable to others.Junio C Hamano2006-06-06
| | | | | | | | | | | The framework to create lockfiles that are removed at exit is first used to reliably write the index file, but it is applicable to other things, so stop calling it "cache_file". This also rewords a few remaining error message that called the index file "cache file". Signed-off-by: Junio C Hamano <junkio@cox.net>
* builtin-rm: squelch compiler warnings.Junio C Hamano2006-05-23
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'lt/dirwalk' into jc/dirwalk-n-cache-treeJunio C Hamano2006-05-20
| | | | | | | | | | | | | | | | | | | | | | | | This commit is what this branch is all about. It records the evil merge needed to adjust built-in git-add and git-rm for the cache-tree extension. * lt/dirwalk: Add builtin "git rm" command Move pathspec matching from builtin-add.c into dir.c Prevent bogus paths from being added to the index. builtin-add: fix unmatched pathspec warnings. Remove old "git-add.sh" remnants builtin-add: warn on unmatched pathspecs Do "git add" as a builtin Clean up git-ls-file directory walking library interface libify git-ls-files directory traversal Conflicts: Makefile builtin.h git.c update-index.c
* Add builtin "git rm" commandLinus Torvalds2006-05-19
This changes semantics very subtly, because it adds a new atomicity guarantee. In particular, if you "git rm" several files, it will now do all or nothing. The old shell-script really looped over the removed files one by one, and would basically randomly fail in the middle if "-f" was used and one of the files didn't exist in the working directory. This C builtin one will not re-write the index after each remove, but instead remove all files at once. However, that means that if "-f" is used (to also force removal of the file from the working directory), and some files have already been removed from the workspace, it won't stop in the middle in some half-way state like the old one did. So what happens is that if the _first_ file fails to be removed with "-f", we abort the whole "git rm". But once we've started removing, we don't leave anything half done. If some of the other files don't exist, we'll just ignore errors of removal from the working tree. This is only an issue with "-f", of course. I think the new behaviour is strictly an improvement, but perhaps more importantly, it is _different_. As a special case, the semantics are identical for the single-file case (which is the only one our test-suite seems to test). The other question is what to do with leading directories. The old "git rm" script didn't do anything, which is somewhat inconsistent. This one will actually clean up directories that have become empty as a result of removing the last file, but maybe we want to have a flag to decide the behaviour? Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-20 17:09:44 +0000