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

Reply via email to