Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > However, if some of the files are of the first kind, and some are of >> > the second kind, you happily apply with mixed strategies. IMO that is >> > wrong. >> >> I'm not sure whether this is really wrong. The things git should >> really care about are the index and the repository itself, and the >> proposed behavior is consistant regarding that (either remove all >> files from the index, or remove none). > > Well, I think it is wrong for the same reason as it is wrong to apply the > changes to _any_ file when one would fail. And since "git apply" shares > my understanding, I think "git rm" should, too. OK, I've been thinking about it for some time (not having time to hack can be good, it lets time for thinking instead ;-) ). I'm actually still not convinced that my proposal was wrong, but I think we disagree because we disagree on what is a "failure". I consider leaving the file in the working tree to be just a safety precaution, not a failure, and to me, it's OK to do that only for the files that need it. Fixing my patch by just "applying the same strategy to all files" would be wrong: leaving _all_ the files on disk when just one has local modifications is very misleading, and if the user notices it after running the command, he or she does not always have an easy way to get back to a clean situation (re-running the same command with -f wouldn't work for example). So, I went a shorter way from the current semantics: * Allow --cached in more situations, so that -f is really needed in very particular situation (as I mentionned above, forcing -f too often means the -f gets hardcoded in the fingers, and makes it useless). * Better error message, which points to --cached in addition to -f. That's very close to what bzr does, BTW. Drawback: it still doesn't solve the "rm isn't the inverse of add". The patch is quite straightforward, and will be in a followup email. -- Matthieu - 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
