Re: [PATCH] t4202 (log): add failing test for log with subtree

[Ramkumar Ramachandra <artagnon@gmail.com>]

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.