Thread (70 messages) flat view 70 messages, 12 authors, 2016-06-15

Re: [PATCH 3/6] Add 'resolve_gitlink_ref()' helper function

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:03


On Tue, 10 Apr 2007, Alex Riesen wrote:
On 4/10/07, Linus Torvalds [off-list ref] wrote:
quoted
That said, it's definitely designed so that if you want to automate
tracking other peoples bare repositories, you can do so: you'd just have
to *really* script it with something like

        git update-index --cacheinfo 0160000 <sha1> <dirname>

(which is how you could create those commits to a bare repo too, so it's
not like this is really even any different)
Nice :)
Well, the *really* nice thing about doing it like this is that you can 
actually update subprojects without even having them even be *local* to 
where you do the superproject.

IOW, you could literally build up the superproject by saying that you want 
to track "all git projects I care about" somewhere else, and do a series 
of automated

	git ls-remote sub-project-xyzzy tracking-branch-xyzzy | ...

and basically create the "superproject" without ever actually downloading 
or populating the subprojects at all.

Then, if everything is set up correctly, you can basically use the 
superproject as an "auto-mirror" - whenever you want to get all the 
projects you care about, you just clone that superproject, and (once 
you've taught "git clone" to fetch the subprojects, of course ;^) you'd 
basically fetch them all from their appropriate locations - without ever 
having the actual superproject have to even *really* care about it.

So basically, a superproject could be used as just a "gathering point", 
without having to actually *contain* any of the subprojects. The actual 
sources for subprojects may be on totally different servers. That's what 
real distribution is all about.

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