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>
2006-05-19 23:19:34 +00:00
|
|
|
/*
|
|
|
|
* "git rm" builtin command
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds 2006
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
|
|
|
#include "builtin.h"
|
|
|
|
#include "dir.h"
|
2006-05-23 08:31:38 +00:00
|
|
|
#include "cache-tree.h"
|
2006-12-25 11:11:00 +00:00
|
|
|
#include "tree-walk.h"
|
2007-10-05 19:09:19 +00:00
|
|
|
#include "parse-options.h"
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
2007-10-05 19:09:19 +00:00
|
|
|
static const char * const builtin_rm_usage[] = {
|
|
|
|
"git-rm [options] [--] <file>...",
|
|
|
|
NULL
|
|
|
|
};
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
|
|
|
static struct {
|
|
|
|
int nr, alloc;
|
|
|
|
const char **name;
|
|
|
|
} list;
|
|
|
|
|
|
|
|
static void add_list(const char *name)
|
|
|
|
{
|
|
|
|
if (list.nr >= list.alloc) {
|
|
|
|
list.alloc = alloc_nr(list.alloc);
|
|
|
|
list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
|
|
|
|
}
|
|
|
|
list.name[list.nr++] = name;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int remove_file(const char *name)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
char *slash;
|
|
|
|
|
|
|
|
ret = unlink(name);
|
2007-01-11 22:58:47 +00:00
|
|
|
if (ret && errno == ENOENT)
|
|
|
|
/* The user has removed it from the filesystem by hand */
|
|
|
|
ret = errno = 0;
|
|
|
|
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
if (!ret && (slash = strrchr(name, '/'))) {
|
2006-09-02 04:16:31 +00:00
|
|
|
char *n = xstrdup(name);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
do {
|
|
|
|
n[slash - name] = 0;
|
|
|
|
name = n;
|
|
|
|
} while (!rmdir(name) && (slash = strrchr(name, '/')));
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-07-13 17:41:38 +00:00
|
|
|
static int check_local_mod(unsigned char *head, int index_only)
|
2006-12-25 11:11:00 +00:00
|
|
|
{
|
|
|
|
/* items in list are already sorted in the cache order,
|
|
|
|
* so we could do this a lot more efficiently by using
|
|
|
|
* tree_desc based traversal if we wanted to, but I am
|
|
|
|
* lazy, and who cares if removal of files is a tad
|
|
|
|
* slower than the theoretical maximum speed?
|
|
|
|
*/
|
|
|
|
int i, no_head;
|
|
|
|
int errs = 0;
|
|
|
|
|
|
|
|
no_head = is_null_sha1(head);
|
|
|
|
for (i = 0; i < list.nr; i++) {
|
|
|
|
struct stat st;
|
|
|
|
int pos;
|
|
|
|
struct cache_entry *ce;
|
|
|
|
const char *name = list.name[i];
|
|
|
|
unsigned char sha1[20];
|
|
|
|
unsigned mode;
|
2007-07-13 17:41:38 +00:00
|
|
|
int local_changes = 0;
|
|
|
|
int staged_changes = 0;
|
2006-12-25 11:11:00 +00:00
|
|
|
|
|
|
|
pos = cache_name_pos(name, strlen(name));
|
|
|
|
if (pos < 0)
|
|
|
|
continue; /* removing unmerged entry */
|
|
|
|
ce = active_cache[pos];
|
|
|
|
|
|
|
|
if (lstat(ce->name, &st) < 0) {
|
|
|
|
if (errno != ENOENT)
|
|
|
|
fprintf(stderr, "warning: '%s': %s",
|
|
|
|
ce->name, strerror(errno));
|
|
|
|
/* It already vanished from the working tree */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else if (S_ISDIR(st.st_mode)) {
|
|
|
|
/* if a file was removed and it is now a
|
|
|
|
* directory, that is the same as ENOENT as
|
|
|
|
* far as git is concerned; we do not track
|
|
|
|
* directories.
|
|
|
|
*/
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (ce_match_stat(ce, &st, 0))
|
2007-07-13 17:41:38 +00:00
|
|
|
local_changes = 1;
|
2007-03-26 18:55:39 +00:00
|
|
|
if (no_head
|
|
|
|
|| get_tree_entry(head, name, sha1, &mode)
|
|
|
|
|| ce->ce_mode != create_ce_mode(mode)
|
|
|
|
|| hashcmp(ce->sha1, sha1))
|
2007-07-13 17:41:38 +00:00
|
|
|
staged_changes = 1;
|
|
|
|
|
|
|
|
if (local_changes && staged_changes)
|
|
|
|
errs = error("'%s' has staged content different "
|
|
|
|
"from both the file and the HEAD\n"
|
|
|
|
"(use -f to force removal)", name);
|
|
|
|
else if (!index_only) {
|
|
|
|
/* It's not dangerous to git-rm --cached a
|
|
|
|
* file if the index matches the file or the
|
|
|
|
* HEAD, since it means the deleted content is
|
|
|
|
* still available somewhere.
|
|
|
|
*/
|
|
|
|
if (staged_changes)
|
|
|
|
errs = error("'%s' has changes staged in the index\n"
|
|
|
|
"(use --cached to keep the file, "
|
|
|
|
"or -f to force removal)", name);
|
|
|
|
if (local_changes)
|
|
|
|
errs = error("'%s' has local modifications\n"
|
|
|
|
"(use --cached to keep the file, "
|
|
|
|
"or -f to force removal)", name);
|
|
|
|
}
|
2006-12-25 11:11:00 +00:00
|
|
|
}
|
|
|
|
return errs;
|
|
|
|
}
|
|
|
|
|
2006-06-06 19:51:49 +00:00
|
|
|
static struct lock_file lock_file;
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
2007-10-05 19:09:19 +00:00
|
|
|
static int show_only = 0, force = 0, index_only = 0, recursive = 0, quiet = 0;
|
|
|
|
static int ignore_unmatch = 0;
|
|
|
|
|
|
|
|
static struct option builtin_rm_options[] = {
|
|
|
|
OPT__DRY_RUN(&show_only),
|
|
|
|
OPT__QUIET(&quiet),
|
|
|
|
OPT_BOOLEAN( 0 , "cached", &index_only, "only remove from the index"),
|
|
|
|
OPT_BOOLEAN('f', NULL, &force, "override the up-to-date check"),
|
|
|
|
OPT_BOOLEAN('r', NULL, &recursive, "allow recursive removal"),
|
|
|
|
OPT_BOOLEAN( 0 , "ignore-unmatch", &ignore_unmatch,
|
|
|
|
"exit with a zero status even if nothing matched"),
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
|
2006-07-29 05:44:25 +00:00
|
|
|
int cmd_rm(int argc, const char **argv, const char *prefix)
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
{
|
|
|
|
int i, newfd;
|
|
|
|
const char **pathspec;
|
|
|
|
char *seen;
|
|
|
|
|
|
|
|
git_config(git_default_config);
|
|
|
|
|
_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>
2007-04-01 06:09:02 +00:00
|
|
|
newfd = hold_locked_index(&lock_file, 1);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
|
|
|
if (read_cache() < 0)
|
|
|
|
die("index file corrupt");
|
|
|
|
|
2007-10-05 19:09:19 +00:00
|
|
|
argc = parse_options(argc, argv, builtin_rm_options, builtin_rm_usage, 0);
|
|
|
|
if (!argc)
|
|
|
|
usage_with_options(builtin_rm_usage, builtin_rm_options);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
2007-11-03 11:23:13 +00:00
|
|
|
if (!index_only)
|
|
|
|
setup_work_tree();
|
|
|
|
|
2007-10-05 19:09:19 +00:00
|
|
|
pathspec = get_pathspec(prefix, argv);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
seen = NULL;
|
2006-06-09 04:11:25 +00:00
|
|
|
for (i = 0; pathspec[i] ; i++)
|
|
|
|
/* nothing */;
|
2006-07-25 07:30:18 +00:00
|
|
|
seen = xcalloc(i, 1);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen))
|
|
|
|
continue;
|
|
|
|
add_list(ce->name);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pathspec) {
|
|
|
|
const char *match;
|
2007-04-16 07:53:24 +00:00
|
|
|
int seen_any = 0;
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
for (i = 0; (match = pathspec[i]) != NULL ; i++) {
|
2007-04-16 07:53:24 +00:00
|
|
|
if (!seen[i]) {
|
|
|
|
if (!ignore_unmatch) {
|
|
|
|
die("pathspec '%s' did not match any files",
|
|
|
|
match);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
seen_any = 1;
|
|
|
|
}
|
2006-12-25 11:11:00 +00:00
|
|
|
if (!recursive && seen[i] == MATCHED_RECURSIVELY)
|
|
|
|
die("not removing '%s' recursively without -r",
|
|
|
|
*match ? match : ".");
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
}
|
2007-04-16 07:53:24 +00:00
|
|
|
|
|
|
|
if (! seen_any)
|
|
|
|
exit(0);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
}
|
|
|
|
|
2006-12-25 11:11:00 +00:00
|
|
|
/*
|
|
|
|
* If not forced, the file, the index and the HEAD (if exists)
|
|
|
|
* must match; but the file can already been removed, since
|
|
|
|
* this sequence is a natural "novice" way:
|
|
|
|
*
|
2007-04-16 08:17:32 +00:00
|
|
|
* rm F; git rm F
|
2006-12-25 11:11:00 +00:00
|
|
|
*
|
|
|
|
* Further, if HEAD commit exists, "diff-index --cached" must
|
|
|
|
* report no changes unless forced.
|
|
|
|
*/
|
|
|
|
if (!force) {
|
|
|
|
unsigned char sha1[20];
|
|
|
|
if (get_sha1("HEAD", sha1))
|
|
|
|
hashclr(sha1);
|
2007-07-13 17:41:38 +00:00
|
|
|
if (check_local_mod(sha1, index_only))
|
2006-12-25 11:11:00 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
/*
|
|
|
|
* First remove the names from the index: we won't commit
|
2006-12-25 11:11:00 +00:00
|
|
|
* the index unless all of them succeed.
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
*/
|
|
|
|
for (i = 0; i < list.nr; i++) {
|
|
|
|
const char *path = list.name[i];
|
2007-04-16 07:46:48 +00:00
|
|
|
if (!quiet)
|
|
|
|
printf("rm '%s'\n", path);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
|
|
|
|
if (remove_file_from_cache(path))
|
2006-08-04 04:55:41 +00:00
|
|
|
die("git-rm: unable to remove %s", path);
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
}
|
|
|
|
|
2006-06-09 04:11:25 +00:00
|
|
|
if (show_only)
|
|
|
|
return 0;
|
|
|
|
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
/*
|
2007-01-11 22:58:47 +00:00
|
|
|
* Then, unless we used "--cached", remove the filenames from
|
2006-12-25 11:11:00 +00:00
|
|
|
* the workspace. If we fail to remove the first one, we
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
* abort the "git rm" (but once we've successfully removed
|
|
|
|
* any file at all, we'll go ahead and commit to it all:
|
2006-07-10 05:50:18 +00:00
|
|
|
* by then we've already committed ourselves and can't fail
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
* in the middle)
|
|
|
|
*/
|
2006-12-25 11:11:00 +00:00
|
|
|
if (!index_only) {
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
int removed = 0;
|
|
|
|
for (i = 0; i < list.nr; i++) {
|
|
|
|
const char *path = list.name[i];
|
|
|
|
if (!remove_file(path)) {
|
|
|
|
removed = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!removed)
|
2006-08-04 04:55:41 +00:00
|
|
|
die("git-rm: %s: %s", path, strerror(errno));
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (active_cache_changed) {
|
|
|
|
if (write_cache(newfd, active_cache, active_nr) ||
|
_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>
2007-04-01 06:09:02 +00:00
|
|
|
close(newfd) || commit_locked_index(&lock_file))
|
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>
2006-05-19 23:19:34 +00:00
|
|
|
die("Unable to write new index file");
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|