Thread (4 messages) flat view 4 messages, 4 authors, 2016-08-11

Re: Subprojects tasks

From: Martin Waitz <hidden>
Date: 2016-08-11 19:48:33

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help