Jan Hudec <bulb@xxxxxx> writes: > If index matches any of that, but the working tree version does not match any > parent, the index entry should be removed (which currently isn't -- that's > the proposed change), but the file left in wokring tree. That would make > git-add + git-rm get you right back where you started, with nothing in index > and unversioned file in working tree. Don't think of 'rm' as inverse of 'add'. That would only confuse you. A natural inverse of 'add' is 'un-add', and that operation is called 'rm --cached', because we use that to name the option to invoke an "index-only" variant of a command when the command can operate on index and working tree file (e.g. "diff --cached", "apply --cached"). A life of a file that does _not_ make into a commit goes like this: [1]$ edit a-new-file This is 'create', not 'add'. git is not involved in this step. [2]$ git add a-new-file This is 'add'; place an existing file in the index. When you do not want it in the index, you 'un-add' it. [3]$ git rm --cached a-new-file This removes the entry from the index, without touching the working tree file. If you do not want that file at all (as opposed to, "I am making a series of partial commits, and the addition of this path does not belong to the first commit of the series, so I am unstaging"), this is followed by [4]$ rm -f a-new-file Again, git is not involved in this step. The thing is, people sometimes want to have steps 3 and 4 combined, and it meshes well with the users' expectation when they see the word "rm". Think of "git rm" without "--cached" as a shorthand to do 3 and 4 in one go to meet that expectation. Obviously, we cannot usefully combine steps 1 and 2. We could have "git add --create a-new-file" launch an editor to create a new file, but that would not be very useful in practice. The fact that steps 3 and 4 can be naturally combined, but steps 1 and 2 cannot be, makes "add" and "rm" not inverse of each other. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
