From: Junio C Hamano Date: Sun, 08 May 2005 05:22:31 GMT Subject: Re: Broken adding of cache entries Message-ID: <7vll6q70mg.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <7vbr7m8p05.fsf@assigned-by-dhcp.cox.net> >>>>> "JCH" == Junio C Hamano writes: JCH> I am not quite sure the semantics is quite right, so I am JCH> holding it off from putting it in git-jc repository for now, but JCH> please review it, give it a try and tell me what you think. Ok, I have two updates pushed out at git-jc archive at http://members.cox.net/junkio/git-jc.git/ Here is the summary of what the changes do. The first commit is to simply prevent Kay's situation from happening from git-update-cache. By default, git-update-cache refuses to: - add "path" when "path/file" exists. That is, you cannot replace a directory with a file (or a symlink). - add "path/file" when "path" exists. That is, you cannot replace a file (or a symlink) with a directory. And the second commit introduces --replace option to the command. When --replace is in effect, instead of refusing, the existing path that conflicts with whatever is being added is dropped with a warning message. That means you would lose an entire subdirectory from the index when you rename it and replace it with a file and then call git-update-cache on it (which is probably fine and what the user expects anyway). Note that this is not enough to prevent nonsensical tree from happening. Three-way read-tree can be fed with an ancestor tree that does not have anything interesting, one side adding "path" (as a file) and the other side adding "path/file". Just after read-tree finishes reading three trees, you would have: 100644 1 not-interesting 100644 2 not-interesting 100644 3 not-interesting 100644 2 path 100644 3 path/file And all of these paths are candidate for trivial "collapsing to stage 0" operation. You would end up with path vs path/file conflicts this way, so the previous change to write-tree to prevent it from writing such a result is still needed. Ideally the "collapsing to stage 0" logic could also be tweaked to detect and prevent this from happening, but I'd rather keep it simple for now (the tool should not be too clever). The user cannot write such a tree, and when this kind of conflict happens, essentially both heads being merged needs to be examined and manual resolution is required anyway.