On Mon, Jun 24, 2019 at 5:52 PM Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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
