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
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