On Tue, 2 Jun 2009, Junio C Hamano wrote: > > Sorry, but I do not quite understand this comment. REV_TREE_NEW can be > treated differently from REV_TREE_DIFFERENT but that only happens if you > know about --remove-empty option, and no scripted (and later converted to > C) Porcelain uses that option by default. It's not REV_TREE_NEW, but the other way around, ie when the commit has no contents but the parent _does_ have contents, maybe we shouldn't then look at another parent and say "no content", and then match that other parent (resulting in no difference). IOW, we are in the situation where one parent gets REV_TREE_SAME, but gets it for a totally pointless reason, namely that neither that parent nor the eventual merge has anything at all in that path. In that case, we simplify towards the parent that results in the smallest diff - which in this case is "nothing there at all". Now, that is often the _right_ thing to do, since if it was meant to be deleted in that branch, then we'll eventually hit the delete commit, and see it as a nice removal. But it does make it really hard to see this case of "unintentional delete" Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html