Please sign in to comment.
rm: do not complain about d/f conflicts during deletion
If we used to have an index entry "d/f", but "d" has been replaced by a non-directory entry, the user may still want to run "git rm" to delete the stale index entry. They could use "git rm --cached" to just touch the index, but "git rm" should also work: we explicitly try to handle the case that the file has already been removed from the working tree. However, because unlinking "d/f" in this case will not yield ENOENT, but rather ENOTDIR, we do not notice that the file is already gone. Instead, we report it as an error. The simple solution is to treat ENOTDIR in this case exactly like ENOENT; all we want to know is whether the file is already gone, and if a leading path is no longer a directory, then by definition the sub-path is gone. Reported-by: jpinheiro <firstname.lastname@example.org> Signed-off-by: Jeff King <email@example.com> Signed-off-by: Junio C Hamano <firstname.lastname@example.org>
- Loading branch information...
Showing with 27 additions and 2 deletions.