Junio C Hamano wrote: > If you need the history context (i.e. M, M^1, M^2) around it to > interpret that additional information, isn't it essentially the same > as storing renames in the merge commit M? There's one big difference. The point is that for any kind of repository composition, you're going to have to store tree renames at some level if you want to be able to move the submodule around in the tree. In the current submodule system, you could say that you're storing tree renames in a blob (submodule.<name>.path in .gitmodules). Ofcourse, the difference is that the other side of the tree entry is completely opaque to the superproject (and I think we can do better than that now). You should use heuristics for all other kinds of renames, but I'm arguing that repository composition is a special case that needs more thought. You shouldn't be against storing renames in principle, because we already do that in a way. What you should be against is storing renames in a way that will lock up the repository if a different path is taken to the same state. What I'm proposing is an optional field to speed up (and make more reliable) rename detection in a very specific case. I'm not putting the information in a commit because that will lock up our repository: If there are two different commits representing the same tree, but one contains bind lines and the other doesn't, we've done something seriously wrong: rebase and merge are screwed. In my case, if there are two perfectly identical trees except that one contains auxiliary information, nothing goes wrong: the tree without the auxiliary information will just be a little slower and can't support DWIM git operations. > Not very impressed, at least not yet. Please bear with me. I really think the repository composition problem is worth solving. -- 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