| Message ID | 20190622122417.28178-1-pclouds@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | rm: add --intent-to-add, to be used with --cached | expand |
Hi Duy, On Sat, 22 Jun 2019, Nguyễn Thái Ngọc Duy wrote: > An index entry serves two purposes: to keep the content to be committed, > and to mark that the same path on worktree is tracked. When > > git rm --cached foo > > is called and there is "foo" in worktree, its status is changed from > tracked to untracked. Which I think is not intended, at least from the > user perspective because we almost always tell people "Git is about the > content" (*). I can buy that rationale. However, I do not think that "remove intent to add" (which is how I read `git rm --intent-to-add`) is a particularly good way to express this. I could see `--keep-intent-to-add` as a better alternative, though. Ciao, Johannes
On Mon, Jun 24, 2019 at 5:52 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Hi Duy, > > On Sat, 22 Jun 2019, Nguyễn Thái Ngọc Duy wrote: > > > An index entry serves two purposes: to keep the content to be committed, > > and to mark that the same path on worktree is tracked. When > > > > git rm --cached foo > > > > is called and there is "foo" in worktree, its status is changed from > > tracked to untracked. Which I think is not intended, at least from the > > user perspective because we almost always tell people "Git is about the > > content" (*). > > I can buy that rationale. However, I do not think that "remove intent to > add" (which is how I read `git rm --intent-to-add`) is a particularly good > way to express this. I could see `--keep-intent-to-add` as a better > alternative, though. Oh good. I also dislike --intent-to-add for a different reasosn but I didn't bring it up: This "rm --intent-to-cache" removes the content and keeps ita, but there's also the potential use case to keep the content and remove ita (e.g. you just want to undo intent-to-add effect, but if you have already staged some content, leave it). This case is about the worktree. But "git rm" is not designed for that. It either handles both index and worktree, or just index. "Just worktree" is delegated to system's "rm". But system "rm" can't do anything about ita bit. And if we make "git rm --worktree" do that, then "rm --worktree --intent-to-add" would be a much better name and should not be taken by this patch. But "git rm --worktree" is not real to even start a discussion about that... End of rambling. I guess what I'm saying is, --keep-intent-to-add is a good name (that I also didn't think of).
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index b5c46223c4..aa0aa6063f 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -60,6 +60,12 @@ OPTIONS Working tree files, whether modified or not, will be left alone. +--intent-to-add:: +--no-intent-to-add:: + When `--cached` is used, if the given path also exist as a + working tree file, the index is updated to record the fact + that the path will be added later, similar to `git add -N`. + --ignore-unmatch:: Exit with a zero status even if no files matched. diff --git a/builtin/rm.c b/builtin/rm.c index be8edc6d1e..135bc4b76e 100644 --- a/builtin/rm.c +++ b/builtin/rm.c @@ -235,12 +235,14 @@ static int check_local_mod(struct object_id *head, int index_only) } static int show_only = 0, force = 0, index_only = 0, recursive = 0, quiet = 0; -static int ignore_unmatch = 0; +static int ignore_unmatch = 0, intent_to_add = 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_BOOL( 0 , "intent-to-add", &intent_to_add, + N_("record that the path will be added later if needed")), OPT__FORCE(&force, N_("override the up-to-date check"), PARSE_OPT_NOCOMPLETE), OPT_BOOL('r', NULL, &recursive, N_("allow recursive removal")), OPT_BOOL( 0 , "ignore-unmatch", &ignore_unmatch, @@ -262,7 +264,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix) if (!argc) usage_with_options(builtin_rm_usage, builtin_rm_options); - if (!index_only) + if (!index_only || intent_to_add) setup_work_tree(); hold_locked_index(&lock_file, LOCK_DIE_ON_ERROR); @@ -344,6 +346,10 @@ int cmd_rm(int argc, const char **argv, const char *prefix) if (remove_file_from_cache(path)) die(_("git rm: unable to remove %s"), path); + + if (index_only && intent_to_add && file_exists(path) && + add_file_to_index(the_repository->index, path, ADD_CACHE_INTENT)) + error(_("failed to mark '%s' as intent-to-add"), path); } if (show_only) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 85ae7dc1e4..04233b7dc4 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -34,6 +34,15 @@ test_expect_success 'Test that git rm foo succeeds' ' git rm --cached foo ' +test_expect_success 'Test that git rm --cached --intent-to-add foo succeeds' ' + echo content >foo && + git add foo && + git rm --cached --intent-to-add foo && + git diff --summary -- foo >actual && + echo " create mode 100644 foo" >expected && + test_cmp expected actual +' + test_expect_success 'Test that git rm --cached foo succeeds if the index matches the file' ' echo content >foo && git add foo &&
An index entry serves two purposes: to keep the content to be committed, and to mark that the same path on worktree is tracked. When git rm --cached foo is called and there is "foo" in worktree, its status is changed from tracked to untracked. Which I think is not intended, at least from the user perspective because we almost always tell people "Git is about the content" (*). Add --intent-to-add, which will replace the current index entry with an intent-to-add one. "git commit -m gone" will record "foo" gone, while "git commit -am not-gone" will ignore the index as usual and keep "foo". Before this, "commit -am" will also remove "foo". While I think --intent-to-add (and also the one in git-reset) should be the default behavior, changing it flip the test suite out because it relies on the current behavior. Let's leave that for later. At least having the ability to just remove the staged content is the right thing to do. (*) From the developer perspective, keeping the tool dumb actually sounds good. When you tell git to remove something from the index, it should go do just that, no trying to be clever. But that's more suitable for plumbing commands like update-index than rm, in my opinion. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- This occurred to me while adding intent-to-add support to git-restore. It's not related to nd/switch-and-restore though and I originally wanted to make it default, so I post it separately here. Documentation/git-rm.txt | 6 ++++++ builtin/rm.c | 10 ++++++++-- t/t3600-rm.sh | 9 +++++++++ 3 files changed, 23 insertions(+), 2 deletions(-)