Re: clarifying two tree merge semantics

By the way, there is one case that you need to keep an eye on if
you are making further fixes to "git-read-tree -m $H $M",
especially now we are talking about keeping what we slurp from
stage0 sometimes:

 (1) index has DF (file)
 (2) $H has DF (file); the index matches it.
 (3) $M has DF/DF (file), implicitly making DF a directory.

For path DF, this rule from the earlier matrix applies:

  exists          exists (index=$H)       no such path        *2*
  * path is removed.

For path DF/DF, this rule from the earlier matrix applies:

  no such path    no such path            exists
  * take $M without complaining.

Thanks to *2*, the current code gets it right and we do not end
up with a cache that records both DF and DF/DF at the same time.
I cannot tell if it is by design or by accident :-).

There is a safety valve at the end of write-tree to refuse to
write out such a nonsensical tree but as Pasky argued back then
(a similar problem was discussed and resolved when you were
away, around the beginning of May, involving update-cache), when
that safety valuve was added, the damage has already been done
if we allow such a cache entry to be created in the first place.

-
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