kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Matthieu Moy	bdecd9d41b	More permissive "git-rm --cached" behavior without -f. 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>	18 years ago
Steven Grimm	bb1faf0d5b	Add --ignore-unmatch option to exit with zero status when no files are removed. Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Steven Grimm	9474eda6c2	git-rm: Trivial fix for a comment typo. Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Steven Grimm	b48caa20de	Add --quiet option to suppress output of "rm" commands for removed files. Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	30ca07a249	_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file. 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>	18 years ago
Jeff King	e4d9516b21	git-rm: don't remove newly added file without -f 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>	18 years ago
Junio C Hamano	a9877f83e0	git-rm documentation: remove broken behaviour from the example. The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	646ac22bdf	git-rm: do not fail on already removed file. 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>	18 years ago
Junio C Hamano	9f95069beb	git-rm: update to saner semantics 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>	18 years ago
Shawn Pearce	9befac470b	Replace uses of strdup with xstrdup. 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>	18 years ago
Junio C Hamano	40aaae88ad	Better error message when we are unable to lock the index file 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>	19 years ago
Junio C Hamano	cba05fa840	Further clean-up: usage() vs die() This hopefully finishes the clean-up Ramsay started with recent commit `15e593e4d3` and commit `8cdf33643d`. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Ramsay Allan Jones	8cdf33643d	Replace some calls to die(usage_str) with usage(usage_str). 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>	19 years ago
Linus Torvalds	a633fca0c0	Call setup_git_directory() much earlier 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>	19 years ago
Peter Eriksen	28f7581806	Substitute xmalloc()+memset(0) with xcalloc(). Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Pavel Roskin	82e5a82fd7	Fix more typos, primarily in the code 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>	19 years ago
Johannes Schindelin	6244b24906	Close the index file between writing and committing Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	7612a1efdb	git-rm: honor -n flag. 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>	19 years ago
Junio C Hamano	021b6e4549	Make index file locking code reusable to others. 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>	19 years ago
Junio C Hamano	3fb3cc69af	builtin-rm: squelch compiler warnings. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	d9b814cc97	Add builtin "git rm" command 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>	19 years ago

22 Commits (3c70183918d97eda06ae847cd7432fd23257caea)