summaryrefslogtreecommitdiff
path: root/builtin-rm.c
AgeCommit message (Collapse)AuthorFilesLines
2007-03-27git-rm: don't remove newly added file without -fLibravatar Jeff King1-14/+4
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>
2007-01-16git-rm documentation: remove broken behaviour from the example.Libravatar Junio C Hamano1-1/+1
The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11git-rm: do not fail on already removed file.Libravatar Junio C Hamano1-1/+5
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>
2006-12-25git-rm: update to saner semanticsLibravatar Junio C Hamano1-20/+103
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>
2006-09-02Replace uses of strdup with xstrdup.Libravatar Shawn Pearce1-1/+1
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>
2006-08-12Better error message when we are unable to lock the index fileLibravatar Junio C Hamano1-3/+1
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>
2006-08-03Further clean-up: usage() vs die()Libravatar Junio C Hamano1-2/+2
This hopefully finishes the clean-up Ramsay started with recent commit 15e593e4d37d1d350fef20ab666d58f6881c7f5f and commit 8cdf33643dc0b21d9ea922a3fdd7f64226c421aa. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-03Replace some calls to die(usage_str) with usage(usage_str).Libravatar Ramsay Allan Jones1-1/+1
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>
2006-07-29Call setup_git_directory() much earlierLibravatar Linus Torvalds1-2/+1
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>
2006-07-25Substitute xmalloc()+memset(0) with xcalloc().Libravatar Peter Eriksen1-2/+1
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Fix more typos, primarily in the codeLibravatar Pavel Roskin1-1/+1
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>
2006-07-08Close the index file between writing and committingLibravatar Johannes Schindelin1-1/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-08git-rm: honor -n flag.Libravatar Junio C Hamano1-7/+10
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>
2006-06-06Make index file locking code reusable to others.Libravatar Junio C Hamano1-3/+3
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>
2006-05-23builtin-rm: squelch compiler warnings.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-20Merge branch 'lt/dirwalk' into jc/dirwalk-n-cache-treeLibravatar Junio C Hamano1-0/+151
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
2006-05-19Add builtin "git rm" commandLibravatar Linus Torvalds1-0/+150
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>