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

Junio C Hamano wrote:

Yeah, you're right. It makes no sense to record renames, although I have a different argument against it: any implementation that records renames will depend on the path that was taken to get to the final state, and this is completely wrong. Subversion made this mistake, and users pay a very heavy price: if the user didn't explicitly rename a node (~= tree) and just did a delete + add, the repository is more-or-less screwed wrt merging.

Forget everything that I said, and let's start over.

In the common usecase of subtrees, it might make sense to record some additional submodule-like parameters in the subtree's tree object. This additional information is entirely optional, and doesn't change the way merges happen: we can have it as merely a heuristic-helper (for git merge -s subtree). Initially, let's just think of putting a ref field in the tree, so that I can have the following setup:

- remote origin referring to my superproject.
- remote git/origin referring to the fetchdefault of my subproject git.
- remote git/ram referring to the pushdefault of my subproject.
- the tree object corresponding to quux/baz/git is additionally filled
in with the ref refs/remotes/git/origin/master.

Then, I can just say git pull quux/baz/git, and it will automatically fetch changes from the ref and merge it into the subtree. It's not to say that I can't merge any other ref; just that I merge this ref most of the time, and I want a DWIM for this case.

Further, this can speed up tree-rename detection greatly (in fact, I'm thinking the first implementation will depend on this information being present). I inspect M^{tree} and I want to know how it's composed from M^1^{tree} and M^2^{tree}. Simple. In M^{tree}, look for trees that have this additional data filled in: then we can just short-circuit the rename detection to matching the similarity of this tree with M^1^{tree} and M^2^{tree}.

When this aux data is present in the tree, we can do one more thing: have a symref tracking the commit-line corresponding to M^2. This means that we can DWIM for things like 'git commit' inside the subtree very easily. When the aux information is not present, 'git commit' will obviously commit to HEAD, essentially making the superproject own those changes in the subtree (as it does now).

This might be the route to implementing narrow clones sensibly. A narrow clone does not mean that any directory in the entire repository can be cloned separately: it just means that a tree with this aux data need not be fetched in the initial clone. For this to work, instead of refs/remotes/git/origin/master, the aux data will need a combination of upstream URL and ref: we can then automatically figure out the name from the URL and deposit the fetched data in refs/remotes/<name>/origin/<ref>.

Initializing nested submodules without the container is also easy: in the superproject, you need to have aux-trees corresponding to quux/baz/git and quux/baz/git/moo/clayoven. It might additionally be a good idea to track these aux-trees: but even if we don't go down that route, we can always deposit a "template" file from the superproject that won't interfere with the subtree merging process.

Now, I'm not sure what the value of splitting the object stores at this point is. The aux-tree can have a statthrough field to block stat() calls from going through, so there's really no performance issue. If you want to separate one tree out of the superproject and work on it separately, all you have to do is fetch the corresponding ref.

On the issue of floating submodules. It might make sense to zero out the hex of the tree, as seen by the superproject. The limitation is that we can't introduce any changes to the submodule from the superproject: it's basically a dummy entry sitting in the superproject's tree. It's a bit of a hack, but I think it's workable.

So, what do you think?