From: Andreas Ericsson <ae@op5.se>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: P Baker <me@retrodict.com>,
"Shawn O. Pearce" <spearce@spearce.org>,
git@vger.kernel.org
Subject: Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
Date: Wed, 01 Apr 2009 08:26:15 +0200 [thread overview]
Message-ID: <49D30907.6090606@op5.se> (raw)
In-Reply-To: <alpine.DEB.1.00.0904010247170.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 31 Mar 2009, P Baker wrote:
>
>> I'll paraphrase to see if I understand your points:
>>
>> *Moving objects from submodule .git directories into the base .git/
>> directory would protect the submodules and is a good idea.
>
> No, I did not say that.
>
> I said that moving submodules' working directory need to protected when
> renaming/deleting submodules.
>
> Even worse, I think that moving the .git/ directory into the
> superproject's .git/ would be at least quite a bit awkward in the nested
> case.
>
Not necessarily. The .git directory of a submodule need not be named .git
inside the superprojects .git directory. I could well imagine something
like this:
.git/modules/submod(.git)/modules/nested-submod(.git)
For deeply nested submodules (eurgh), one might run into path length limit
issues though. The point is that we will need some library-like function
to find the repository of the submodule. Once that's done, the same call
with a different $gitdir should be able to find the nested submodule.
I'm also thinking of libgit2 here, where each repository will be
represented as a struct that must be passed to the various $gitdir
searching functions. This is necessary to allow a single program to access
multiple repositories, and the .git/modules scheme makes supporting
submodules in the library quite trivial.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
next prev parent reply other threads:[~2009-04-01 6:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 20:14 [RFC GSoC 2009: git-submodule for multiple, active developers on active trees] P Baker
2009-03-30 15:32 ` Shawn O. Pearce
2009-03-31 15:30 ` P Baker
2009-03-31 15:57 ` Johannes Schindelin
2009-03-31 22:32 ` P Baker
2009-03-31 23:05 ` Johannes Schindelin
2009-03-31 23:49 ` P Baker
2009-04-01 0:58 ` Johannes Schindelin
2009-04-01 2:47 ` P Baker
2009-04-01 16:10 ` Johannes Schindelin
2009-04-01 6:26 ` Andreas Ericsson [this message]
2009-04-01 16:13 ` Johannes Schindelin
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=49D30907.6090606@op5.se \
--to=ae@op5.se \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=me@retrodict.com \
--cc=spearce@spearce.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.