From: "Martin Langhoff" <martin.langhoff@gmail.com>
To: "Jakub Narebski" <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Submodules use case: web development based on modular CMS
Date: Sun, 27 Jan 2008 16:00:52 +1300 [thread overview]
Message-ID: <46a038f90801261900s2c4fa348wd5e0aea4ed9f1c12@mail.gmail.com> (raw)
In-Reply-To: <200801270139.57830.jnareb@gmail.com>
On Jan 27, 2008 1:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> A bit of time ago I have stumbled upon the following blog entry
> (question): "Agaric wants version control that lets Drupal core and
> contrib replace entire directories within our checkouts"[1]
> http://tinyurl.com/yv3jp4
While it is possible to use submodules, I tend to think that you can
just use your own repo / branch "off" the main project, just like
unofficial kernel modules do.
It does have a number of advantages -- including being explicit wrt to
what version of the core project the module is developed against.
Drupal and similar projects (like Moodle) do have a module API, but
it's not *that* stable -- in spite of the best intentions, those APIs
get subtle changes all the time. You should have your "release" script
package only the module subdirectories -- and perhaps any delta in the
core (of Drupal) that needs to be applied. In many "contrib" projects
I've seen module files and little patch files that you are supposed to
apply - and maintenance of those is a pain. It makes more sense to use
git over the whole tree.
So it's a tradeoff -- IMHO, at first blush it looks more "natural" to
use submodules, but as things progress over time I think it forces a
lot of additional and ill-fitted work like maintaining patches, or
adding tags that indicate "developed against Drupal v1.2.3". And the
day the contrib module becomes official, "merging it in" is a bit of a
mess if you want to preserve history. So in the long haul, it makes a
lot more sense to use the "branch off the full project" approach that
has served the kernel modules so well.
In that sense, I think that gitk's tree getting merged in a
subdirectory is good as an example of what git can do, but a bit
pointless as gitk depend quite tightly on the behaviour of git
commands. So distributing gitk separately would be a big pain as each
gitk version is usable against a narrow set of git revisions. Luckily,
it gets merged into git and that's how it gets distributed.
My .2c anyway ;-)
m
next prev parent reply other threads:[~2008-01-27 3:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-27 0:39 Submodules use case: web development based on modular CMS Jakub Narebski
2008-01-27 3:00 ` Martin Langhoff [this message]
2008-01-27 18:23 ` Jakub Narebski
2008-01-28 10:44 ` Jakub Narebski
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=46a038f90801261900s2c4fa348wd5e0aea4ed9f1c12@mail.gmail.com \
--to=martin.langhoff@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/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).