summaryrefslogtreecommitdiff
path: root/builtin-rm.c
AgeCommit message (Collapse)AuthorFilesLines
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>