Junio C Hamano wrote: > I have forgotten about this topic (and its numerous iterations in > the past), but it appears me that people mostly lost interest after > v7 review cycle where the series looked like a solution that is > looking for a problem.
I agree. Over-generalizing the problem is going nowhere. I have some ideas in my head, but I think I'm at the brink of insanity again: We have a special type of merge commit that has 'bind' lines corresponding to the trees of the commits we just merged in: each line references a tree and a prefix. Then, a diff between the merge's tree and one of these trees can easily tell us what changes were introduced by each side. And here's the bomb: if we consider extending it to include a blob-like buffer, we can use it to store submodule-like information for each prefix. Everything would just work out of the box with a few minor adjustments: 1. We have to modify our packing algorithm to not reach out beyond ^1 of these special merge commits. This means object-store isolation (not $GITDIR isolation). And it means that submodules can be cloned and removed at will. 2. We have to maintain a symbolic ref for each prefix. A commit invoked from a special-commit referenced subdirectory will update this symref. Ofcourse, this means that we need to namespace our refs/ and refs/remotes sensibly. 3. Git commands will take into account $CWD very strongly, and just DTRT all the time. Whether you're looking from the submodule perspective or the superproject perspective. Am I making any sense? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
