Jeff King <peff@xxxxxxxx> writes: > OTOH, clearly git-add can "lose" data in this way as well, since a > "modify, git-add, modify, git-add" will "lose" any reference to the > index state after the first add. So maybe that is not worth worrying > about at all (in which case our safety valve is too strict in many > places). Exactly. And not considering that lossage helps us keep our sanity. I think "git rm --cached" falls into the same category. If the user wants to discard what is in the index without losing a copy in the working tree, I think we should let him do without fuss. > git-add foo > echo changes >>foo > # oops, I don't want to commit foo just yet > git-rm --cached foo > > but in that case, maybe the user doesn't actually _care_ about that > intermediate state of 'foo'. Yes, that is (at least, "used to be") exactly the use case "rm --cached" is supposed to help. Added something prematurely to the index, not ready to commit that part of the changes yet. Of course you could do partial commits with "add --interactive" these days, so there is not as much need for this as it used to be anymore. - 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
