From: Martin Waitz <tali@admingilde.org>
To: skimo@liacs.nl
Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>
Subject: Re: [RFC] Third round of support for cloning submodules
Date: Mon, 21 May 2007 00:52:53 +0200 [thread overview]
Message-ID: <20070520225252.GO5412@admingilde.org> (raw)
In-Reply-To: <11796842882917-git-send-email-skimo@liacs.nl>
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
hoi :)
On Sun, May 20, 2007 at 08:04:33PM +0200, skimo@liacs.nl wrote:
> This patch series implements a mechanism for cloning submodules.
> Each submodule is specified by a 'submodule.<submodule>.url'
> configuration option, e.g.,
>
> bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
> submodule.cloog.url /home/sverdool/public_html/cloog.git
> submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
I really think we should try to find one standard method to
automatically find the right parent repository for a submodule,
based on the supermodules parent repository.
So e.g. that the submodule repository should stay in the same directory
or in some special subdirectory of the supermodule or even in the
same object store.
Then we can add a configuration layor on top, but there should always
be a sane default.
Things we have to think about:
* we have to cope with moving / disappearing repositories.
* we should support bare repositories even for superprojects.
This can be done either by including the submodule objects in
the bare repository directly or by linking them (e.g. with your
config implementation)
* we have to keep old submodules around forever,
at least when we want to be able to recover old versions.
Of course this is not required for all working copies as people
only want to have a subset of needed modules.
But for central synchronization repositories (probably the bare ones)
this is really important.
* If you remove the whole working directory I don't want to loose any
data which is already committed, including submodules.
That leads to submodules which store their objects within the
supermodule .git directory, which would automatically obsolete the
need to specify explicit submodule URLs. But I'm not quite sure
on how to really do this, despite having experimented a bit with it
(my module3 branch should still contain some brainstorming and code).
So back to your code: I don't like absolute URLs in the cloneable part
of the repository. We should try to stay with relative ones which
can stay the same everywhere.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-05-20 22:53 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 18:04 [RFC] Third round of support for cloning submodules skimo
2007-05-20 18:04 ` [PATCH 01/15] Add dump-config skimo
2007-05-20 18:04 ` [PATCH 02/15] git-config: add --remote option for reading config from remote repo skimo
2007-05-20 18:11 ` Frank Lichtenheld
2007-05-20 19:44 ` Sven Verdoolaege
2007-05-20 22:03 ` Frank Lichtenheld
2007-05-20 18:04 ` [PATCH 03/15] http.h: make fill_active_slots a function pointer skimo
2007-05-20 18:04 ` [PATCH 04/15] git-config: read remote config files over HTTP skimo
2007-05-20 18:04 ` [PATCH 05/15] unpack-trees.c: pass cache_entry * to verify_absent rather than just the name skimo
2007-05-20 18:04 ` [PATCH 06/15] git-read-tree: take --submodules option skimo
2007-05-20 21:24 ` Martin Waitz
2007-05-20 21:50 ` Sven Verdoolaege
2007-05-20 18:04 ` [PATCH 07/15] unpack-trees.c: assume submodules are clean skimo
2007-05-20 18:04 ` [PATCH 08/15] Add run_command_v_opt_cd: chdir into a directory before exec skimo
2007-05-20 18:04 ` [PATCH 09/15] entry.c: optionally checkout submodules skimo
2007-05-20 21:18 ` Martin Waitz
2007-05-20 21:51 ` Sven Verdoolaege
2007-05-24 13:29 ` Sven Verdoolaege
2007-05-20 18:04 ` [PATCH 10/15] git-checkout: pass --submodules option to git-read-tree skimo
2007-05-20 18:04 ` [PATCH 11/15] git-read-tree: treat null commit as empty tree skimo
2007-05-20 18:04 ` [PATCH 12/15] git_config: add void * for callback data skimo
2007-05-20 18:04 ` [PATCH 13/15] unpack-trees.c: optionally clone submodules for later checkout skimo
2007-05-20 18:04 ` [PATCH 14/15] entry.c: optionall checkout newly cloned submodules skimo
2007-05-20 18:04 ` [PATCH 15/15] git-clone: add --submodules for cloning submodules skimo
2007-05-20 19:10 ` [RFC] Third round of support " Junio C Hamano
2007-05-20 19:59 ` Sven Verdoolaege
2007-05-20 20:54 ` Alex Riesen
2007-05-20 21:09 ` Sven Verdoolaege
2007-05-20 21:24 ` Alex Riesen
2007-05-20 21:47 ` Sven Verdoolaege
2007-05-20 22:26 ` Alex Riesen
2007-05-21 9:57 ` Sven Verdoolaege
2007-05-21 10:44 ` Josef Weidendorfer
2007-05-21 11:41 ` Martin Waitz
2007-05-20 21:40 ` Martin Waitz
2007-05-20 22:24 ` Alex Riesen
2007-05-20 22:55 ` Martin Waitz
2007-05-20 23:02 ` Alex Riesen
2007-05-20 23:12 ` Martin Waitz
2007-05-22 21:54 ` Alex Riesen
2007-05-24 15:56 ` Martin Waitz
2007-05-21 0:39 ` Steven Grimm
2007-05-21 10:01 ` Sven Verdoolaege
2007-05-22 21:56 ` Alex Riesen
2007-05-20 22:14 ` Martin Waitz
2007-05-20 22:58 ` Alex Riesen
2007-05-20 23:36 ` Martin Waitz
2007-05-20 22:52 ` Martin Waitz [this message]
2007-05-21 8:54 ` Sven Verdoolaege
2007-05-21 10:07 ` Martin Waitz
2007-05-21 10:14 ` Sven Verdoolaege
2007-05-21 11:34 ` Martin Waitz
2007-05-21 12:19 ` Sven Verdoolaege
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070520225252.GO5412@admingilde.org \
--to=tali@admingilde.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=skimo@liacs.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).