Re: Git submodule enhancements

["P. Christeas" <p_christ@hol.gr>]

On Wednesday 24 September 2008, Lars Hjemli wrote:
> It looks like --cloned requires the downstream to know which
> submodules are available from the same remote as the supermodule (and
> with the same path as registered in the supermodule), i.e. quite a
> specific configuration. Is this really common enough to justify a
> special option to `submodule init`?
I agree. My patch is only a temporary fix for the situation and may not cover 
all needs.

> Maybe the .gitmodules file could be extended to contain multiple urls
> instead (i.e. both absolute and relative ones)? Then `submodule init`
> could get options like --prefer-relative-url, --prefer-absolute-url
> and --interactive. What do you think?
I guess there is much room for improvement wrt. with the .gitmodules . For 
one, they should try to mimic the 'git clone' refspec logic, instead of being 
a static file. (in fact, the hooks could let us do that using scripts alone)

> Hmm, after reading through this once more I guess you're trying to
> clone a non-bare repository, possibly also lacking a .gitmodules file
> (hence the --force)?
Not really. I was trying to have the git-submodule script re-write the conf 
with a different url. Merely like running a 'submodule sync' at the same 
time.

> Btw: why doesn't
>   $ git submodule foreach 'git archive HEAD > somewhere/$path.tar'
> work for you?
In fact, it could. You could also replace HEAD with the $sha1 ..

In general, my comment on submodules is that it is a very powerful concept, 
but still lacks many real-life features. Reading the C code, I realized that 
we would have to rework all the core plumbing of git in order to have it work 
accross different git repos inside the same C process. That is a stopper. 
Otherwise, if we could only have read_tree_recursive() span to different gits, 
we could do really beautiful things.

Sorry for posting many ideas and only few patches!