Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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" I realize that "--simplify-merges" would show that kind of deletion. E.g. "git log --graph --oneline -- git-clone.sh" shows that the scripted version ceased to exist at 8434c2f (Build in clone, 2008-04-27), but with the option, b84c343 (Merge branch 'db/clone-in-c', 2008-05-25) merged the deletion to the mainline, but while doing so we lost two updates to the scripted version since the "Build in clone" topic forked. -- 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