Having said that, I think this comment is not quite right.
+ else if (!index_only) {
+ /* It's not dangerous to git-rm --cached a
+ * file if the index matches the file or the
+ * HEAD, since it means the deleted content is
+ * still available somewhere.
+ */
Personally I do not think "rm --cached" needs any such "safety",
even though I'll keep the check for now, primarily because
loosening the restriction later is always easier than adding new
restriction. I really do not think this is about protecting the
user from "deleted content is not available anywhere else".
In this sequence:
edit a-new-file
git add a-new-file
edit a-new-file
git add a-new-file
we do not complain, even though we are *losing* the contents we
earlier staged. If you replace the second "git add" with
"git-rm --cached", the sequence should work the same way. In
either case, you are working towards your next commit, and most
likely are doing a partial commit (iow, your working tree does
not match any of the commit you create in the middle). Earlier
you thought you would want one state of the file in the next
commit, but now you decided against putting that new file in the
first commit in the series. You may make further updates to the
index and would make a commit, but after making the commit, your
working tree still has "a-new-file" and you can add the contents
from it for the later commit.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
