Sven Verdoolaege [off-list ref] writes:
On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
quoted
I suspect the hardest part is "rev-list --objects" (now most of
it is found in revision.c). [..] But I think the updated
code needs to know that "link" needs to be unwrapped and
contained "commit" needs to be injected back to the ancestry
walking machinery.
Do we want "link" to be unwrapped, though ?
quoted
Once you have "rev-list --objects", you should be able to drive
pack-objects with its output.
Wouldn't we then run into the scalability problems Linus was
concerned about ?
Hmph.
If the plumbing layer does not have to (although I haven't
thought it through, it does feel like it even shouldn't) unwrap
"link" and let the Porcelain layer to deal with it, that would
certainly make rev-list/revision.c part simpler.
I like it.
On Saturday 16 December 2006 23:58, Martin Waitz wrote:
quoted
If the plumbing layer does not have to (although I haven't
thought it through, it does feel like it even shouldn't) unwrap
"link" and let the Porcelain layer to deal with it, that would
certainly make rev-list/revision.c part simpler.
Yes. However, it makes other things more complicated.
If the plumbing does not do all the subproject stuff and you don't have
everything in one database
Even without plumbing doing the subproject stuff, we could use the
same, unified database for the objects. Or do I miss something?
As you said: the problem are submodule commit in superproject trees which
are not reachable by refs of the submodule. However, we only need these
commits when cloning/fetching the submodule in the scope of cloning/fetching
the superproject; we simply can not use here a normal repository of the
submodule, as these commits would be not available there.
We should add a plumbing command for "Give me the minimal set of commits
(from all submodules) which have all the submodule link object ids as ancestors
which appear in the history of a given commit (from a superproject)".
With this, building the set of objects to pack/fetch/clone into a unified
object database for a superproject with its submodules should be easy.
It is also needed for pruning the unified object database.
Pruning in submodules simply would print out an error "Pruning in submodules
not supported. Prune in the superproject instead".
Josef
hoi :)
Junio, I'll take a more detailed look at your mail tomorrow, after I
regenerated from all the Guinness I had tonight ;-)
On Sat, Dec 16, 2006 at 01:07:04PM -0800, Junio C Hamano wrote:
Sven Verdoolaege [off-list ref] writes:
quoted
On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
quoted
I suspect the hardest part is "rev-list --objects" (now most of
it is found in revision.c). [..] But I think the updated
code needs to know that "link" needs to be unwrapped and
contained "commit" needs to be injected back to the ancestry
walking machinery.
Well, I already got to the point of using the commit directly,
instead of any link object. It even worked with rev-list --objects
in all my test cases. That is, I could correctly clone/pack/pull
the complete project including all modules.
quoted
Wouldn't we then run into the scalability problems Linus was
concerned about ?
This is a real problem.
If the plumbing layer does not have to (although I haven't
thought it through, it does feel like it even shouldn't) unwrap
"link" and let the Porcelain layer to deal with it, that would
certainly make rev-list/revision.c part simpler.
Yes. However, it makes other things more complicated.
If the plumbing does not do all the subproject stuff and you don't have
everything in one database it is much more difficult to really get
a consistent database when cloning or fetching (you have to get even old
submodule commits which are not reachable by the current supermodule
tree anymore, perhaps even submodules which do not exist anymore).
I did not have much time to think about these issues in the last day and
am not yet convinced on how to proceed,
--
Martin Waitz
On Sat, Dec 16, 2006 at 11:58:10PM +0100, Martin Waitz wrote:
On Sat, Dec 16, 2006 at 01:07:04PM -0800, Junio C Hamano wrote:
quoted
Sven Verdoolaege [off-list ref] writes:
quoted
On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
quoted
I suspect the hardest part is "rev-list --objects" (now most of
it is found in revision.c). [..] But I think the updated
code needs to know that "link" needs to be unwrapped and
contained "commit" needs to be injected back to the ancestry
walking machinery.
Well, I already got to the point of using the commit directly,
instead of any link object.
I think Junio is simply refering to the type of the object as represented
in a tree and that the value would indeed just be the commit hash, as in
your implementation.