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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 22, 2013, 22:52 UTC
Message-ID: <CALkWK0mO0L4YrZFGmzWkiO4V18p-ydKyjVOe4vJ2H-d7Kz+qOw@mail.gmail.com>
In-Reply-To: <7vmwsqns4p.fsf@alter.siamese.dyndns.org>

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?