[PATCH] rm: add --intent-to-add, to be used with --cached

[PATCH] rm: add --intent-to-add, to be used with --cached

[Nguyễn Thái Ngọc Duy]

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(-)

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 &&
-- 
2.22.0.rc0.322.g2b0371e29a

Re: [PATCH] rm: add --intent-to-add, to be used with --cached

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

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

Re: [PATCH] rm: add --intent-to-add, to be used with --cached

[Duy Nguyen]

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).
-- 
Duy