git/builtin/rm.c

396 lines
10 KiB
C
Raw Normal View History

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-20 07:19:34 +08:00
/*
* "git rm" builtin command
*
* Copyright (C) Linus Torvalds 2006
*/
#include "builtin.h"
#include "lockfile.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-20 07:19:34 +08:00
#include "dir.h"
#include "cache-tree.h"
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>
2006-12-25 19:11:00 +08:00
#include "tree-walk.h"
#include "parse-options.h"
#include "string-list.h"
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
#include "submodule.h"
#include "pathspec.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-20 07:19:34 +08:00
static const char * const builtin_rm_usage[] = {
N_("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-20 07:19:34 +08:00
static struct {
int nr, alloc;
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
struct {
const char *name;
char is_submodule;
} *entry;
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-20 07:19:34 +08:00
} list;
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
static int get_ours_cache_pos(const char *path, int pos)
{
int i = -pos - 1;
while ((i < active_nr) && !strcmp(active_cache[i]->name, path)) {
if (ce_stage(active_cache[i]) == 2)
return i;
i++;
}
return -1;
}
static void print_error_files(struct string_list *files_list,
const char *main_msg,
const char *hints_msg,
int *errs)
{
if (files_list->nr) {
int i;
struct strbuf err_msg = STRBUF_INIT;
strbuf_addstr(&err_msg, main_msg);
for (i = 0; i < files_list->nr; i++)
strbuf_addf(&err_msg,
"\n %s",
files_list->items[i].string);
if (advice_rm_hints)
strbuf_addstr(&err_msg, hints_msg);
*errs = error("%s", err_msg.buf);
strbuf_release(&err_msg);
}
}
static void submodules_absorb_gitdir_if_needed(const char *prefix)
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
{
int i;
for (i = 0; i < list.nr; i++) {
const char *name = list.entry[i].name;
int pos;
Convert "struct cache_entry *" to "const ..." wherever possible I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 23:29:00 +08:00
const struct cache_entry *ce;
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
pos = cache_name_pos(name, strlen(name));
if (pos < 0) {
pos = get_ours_cache_pos(name, pos);
if (pos < 0)
continue;
}
ce = active_cache[pos];
if (!S_ISGITLINK(ce->ce_mode) ||
!file_exists(ce->name) ||
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
is_empty_dir(name))
continue;
if (!submodule_uses_gitfile(name))
absorb_git_dir_into_superproject(prefix, name,
ABSORB_GITDIR_RECURSE_SUBMODULES);
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
}
}
static int check_local_mod(struct object_id *head, int index_only)
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>
2006-12-25 19:11:00 +08:00
{
/*
* Items in list are already sorted in the cache order,
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>
2006-12-25 19:11:00 +08:00
* 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;
struct string_list files_staged = STRING_LIST_INIT_NODUP;
struct string_list files_cached = STRING_LIST_INIT_NODUP;
struct string_list files_local = STRING_LIST_INIT_NODUP;
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>
2006-12-25 19:11:00 +08:00
no_head = is_null_oid(head);
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>
2006-12-25 19:11:00 +08:00
for (i = 0; i < list.nr; i++) {
struct stat st;
int pos;
Convert "struct cache_entry *" to "const ..." wherever possible I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 23:29:00 +08:00
const struct cache_entry *ce;
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
const char *name = list.entry[i].name;
struct object_id oid;
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>
2006-12-25 19:11:00 +08:00
unsigned mode;
int local_changes = 0;
int staged_changes = 0;
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>
2006-12-25 19:11:00 +08:00
pos = cache_name_pos(name, strlen(name));
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
if (pos < 0) {
/*
* Skip unmerged entries except for populated submodules
* that could lose history when removed.
*/
pos = get_ours_cache_pos(name, pos);
if (pos < 0)
continue;
if (!S_ISGITLINK(active_cache[pos]->ce_mode) ||
is_empty_dir(name))
continue;
}
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>
2006-12-25 19:11:00 +08:00
ce = active_cache[pos];
if (lstat(ce->name, &st) < 0) {
if (errno != ENOENT && errno != ENOTDIR)
warning_errno(_("failed to stat '%s'"), ce->name);
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>
2006-12-25 19:11:00 +08:00
/* 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
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
* directories unless they are submodules.
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>
2006-12-25 19:11:00 +08:00
*/
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
if (!S_ISGITLINK(ce->ce_mode))
continue;
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>
2006-12-25 19:11:00 +08:00
}
/*
* "rm" of a path that has changes need to be treated
* carefully not to allow losing local changes
* accidentally. A local change could be (1) file in
* work tree is different since the index; and/or (2)
* the user staged a content that is different from
* the current commit in the index.
*
* In such a case, you would need to --force the
* removal. However, "rm --cached" (remove only from
* the index) is safe if the index matches the file in
* the work tree or the HEAD commit, as it means that
* the content being removed is available elsewhere.
*/
/*
* Is the index different from the file in the work tree?
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
* If it's a submodule, is its work tree modified?
*/
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
if (ce_match_stat(ce, &st, 0) ||
(S_ISGITLINK(ce->ce_mode) &&
bad_to_remove_submodule(ce->name,
SUBMODULE_REMOVAL_DIE_ON_ERROR |
SUBMODULE_REMOVAL_IGNORE_IGNORED_UNTRACKED)))
local_changes = 1;
/*
* Is the index different from the HEAD commit? By
* definition, before the very initial commit,
* anything staged in the index is treated by the same
* way as changed from the HEAD.
*/
if (no_head
|| get_tree_entry(head->hash, name, oid.hash, &mode)
|| ce->ce_mode != create_ce_mode(mode)
|| oidcmp(&ce->oid, &oid))
staged_changes = 1;
/*
* If the index does not match the file in the work
* tree and if it does not match the HEAD commit
* either, (1) "git rm" without --cached definitely
* will lose information; (2) "git rm --cached" will
* lose information unless it is about removing an
* "intent to add" entry.
*/
if (local_changes && staged_changes) {
if (!index_only || !ce_intent_to_add(ce))
string_list_append(&files_staged, name);
}
else if (!index_only) {
if (staged_changes)
string_list_append(&files_cached, name);
if (local_changes)
string_list_append(&files_local, name);
}
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>
2006-12-25 19:11:00 +08:00
}
print_error_files(&files_staged,
Q_("the following file has staged content different "
"from both the\nfile and the HEAD:",
"the following files have staged content different"
" from both the\nfile and the HEAD:",
files_staged.nr),
_("\n(use -f to force removal)"),
&errs);
string_list_clear(&files_staged, 0);
print_error_files(&files_cached,
Q_("the following file has changes "
"staged in the index:",
"the following files have changes "
"staged in the index:", files_cached.nr),
_("\n(use --cached to keep the file,"
" or -f to force removal)"),
&errs);
string_list_clear(&files_cached, 0);
print_error_files(&files_local,
Q_("the following file has local modifications:",
"the following files have local modifications:",
files_local.nr),
_("\n(use --cached to keep the file,"
" or -f to force removal)"),
&errs);
string_list_clear(&files_local, 0);
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>
2006-12-25 19:11:00 +08:00
return errs;
}
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-20 07:19:34 +08: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, N_("dry run")),
OPT__QUIET(&quiet, N_("do not list removed files")),
OPT_BOOL( 0 , "cached", &index_only, N_("only remove from the index")),
OPT__FORCE(&force, N_("override the up-to-date check")),
OPT_BOOL('r', NULL, &recursive, N_("allow recursive removal")),
OPT_BOOL( 0 , "ignore-unmatch", &ignore_unmatch,
N_("exit with a zero status even if nothing matched")),
OPT_END(),
};
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-20 07:19:34 +08:00
{
int i;
struct pathspec pathspec;
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-20 07:19:34 +08:00
char *seen;
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07 03:15:25 +08:00
gitmodules_config();
git_config(git_default_config, 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-20 07:19:34 +08:00
argc = parse_options(argc, argv, prefix, 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-20 07:19:34 +08:00
if (!index_only)
setup_work_tree();
hold_locked_index(): align error handling with hold_lockfile_for_update() Callers of the hold_locked_index() function pass 0 when they want to prepare to write a new version of the index file without wishing to die or emit an error message when the request fails (e.g. somebody else already held the lock), and pass 1 when they want the call to die upon failure. This option is called LOCK_DIE_ON_ERROR by the underlying lockfile API, and the hold_locked_index() function translates the paramter to LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update(). Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop translating. Callers other than the ones that are replaced with this change pass '0' to the function; no behaviour change is intended with this patch. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Among the callers of hold_locked_index() that passes 0: - diff.c::refresh_index_quietly() at the end of "git diff" is an opportunistic update; it leaks the lockfile structure but it is just before the program exits and nobody should care. - builtin/describe.c::cmd_describe(), builtin/commit.c::cmd_status(), sequencer.c::read_and_refresh_cache() are all opportunistic updates and they are OK. - builtin/update-index.c::cmd_update_index() takes a lock upfront but we may end up not needing to update the index (i.e. the entries may be fully up-to-date), in which case we do not need to issue an error upon failure to acquire the lock. We do diagnose and die if we indeed need to update, so it is OK. - wt-status.c::require_clean_work_tree() IS BUGGY. It asks silence, does not check the returned value. Compare with callsites like cmd_describe() and cmd_status() to notice that it is wrong to call update_index_if_able() unconditionally.
2016-12-08 02:33:54 +08:00
hold_locked_index(&lock_file, LOCK_DIE_ON_ERROR);
if (read_cache() < 0)
die(_("index file corrupt"));
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD |
PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
prefix, argv);
refresh_index(&the_index, REFRESH_QUIET, &pathspec, NULL, NULL);
seen = xcalloc(pathspec.nr, 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-20 07:19:34 +08:00
for (i = 0; i < active_nr; i++) {
Convert "struct cache_entry *" to "const ..." wherever possible I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 23:29:00 +08:00
const struct cache_entry *ce = active_cache[i];
if (!ce_path_match(ce, &pathspec, seen))
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-20 07:19:34 +08:00
continue;
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
ALLOC_GROW(list.entry, list.nr + 1, list.alloc);
list.entry[list.nr].name = xstrdup(ce->name);
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07 03:15:25 +08:00
list.entry[list.nr].is_submodule = S_ISGITLINK(ce->ce_mode);
if (list.entry[list.nr++].is_submodule &&
!is_staging_gitmodules_ok())
die (_("Please stage your changes to .gitmodules or stash them to proceed"));
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-20 07:19:34 +08:00
}
if (pathspec.nr) {
const char *original;
int seen_any = 0;
for (i = 0; i < pathspec.nr; i++) {
original = pathspec.items[i].original;
if (!seen[i]) {
if (!ignore_unmatch) {
die(_("pathspec '%s' did not match any files"),
original);
}
}
else {
seen_any = 1;
}
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>
2006-12-25 19:11:00 +08:00
if (!recursive && seen[i] == MATCHED_RECURSIVELY)
die(_("not removing '%s' recursively without -r"),
*original ? original : ".");
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-20 07:19:34 +08: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-20 07:19:34 +08:00
}
if (!index_only)
submodules_absorb_gitdir_if_needed(prefix);
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>
2006-12-25 19:11:00 +08: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:
*
* rm F; git rm F
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>
2006-12-25 19:11:00 +08:00
*
* Further, if HEAD commit exists, "diff-index --cached" must
* report no changes unless forced.
*/
if (!force) {
struct object_id oid;
if (get_oid("HEAD", &oid))
oidclr(&oid);
if (check_local_mod(&oid, index_only))
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>
2006-12-25 19:11:00 +08: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-20 07:19:34 +08:00
/*
* First remove the names from the index: we won't commit
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>
2006-12-25 19:11:00 +08: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-20 07:19:34 +08:00
*/
for (i = 0; i < list.nr; i++) {
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
const char *path = list.entry[i].name;
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-20 07:19:34 +08:00
if (remove_file_from_cache(path))
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-20 07:19:34 +08: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-20 07:19:34 +08:00
/*
* Then, unless we used "--cached", remove the filenames from
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>
2006-12-25 19:11:00 +08: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-20 07:19:34 +08:00
* abort the "git rm" (but once we've successfully removed
* any file at all, we'll go ahead and commit to it all:
* 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-20 07:19:34 +08:00
* in the middle)
*/
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>
2006-12-25 19:11:00 +08:00
if (!index_only) {
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07 03:15:25 +08:00
int removed = 0, gitmodules_modified = 0;
struct strbuf buf = STRBUF_INIT;
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-20 07:19:34 +08:00
for (i = 0; i < list.nr; i++) {
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
const char *path = list.entry[i].name;
if (list.entry[i].is_submodule) {
strbuf_reset(&buf);
strbuf_addstr(&buf, path);
if (remove_dir_recursively(&buf, 0))
die(_("could not remove '%s'"), path);
removed = 1;
if (!remove_path_from_gitmodules(path))
gitmodules_modified = 1;
continue;
submodule: teach rm to remove submodules unless they contain a git directory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-27 02:21:13 +08:00
}
if (!remove_path(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-20 07:19:34 +08:00
removed = 1;
continue;
}
if (!removed)
die_errno("git rm: '%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-20 07:19:34 +08:00
}
strbuf_release(&buf);
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07 03:15:25 +08:00
if (gitmodules_modified)
stage_updated_gitmodules();
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-20 07:19:34 +08:00
}
if (active_cache_changed) {
if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
die(_("Unable to write new index 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-20 07:19:34 +08:00
}
return 0;
}