Re: Broken adding of cache entries

[Junio C Hamano <junkio@cox.net>]

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> 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.