Re: RFC: a plugin architecture for git extensions?
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Apr 27, 2011, 11:57 UTC
- Message-ID
- <BANLkTimUPGqVcn743P-Hkf_BaS9XT93=ZQ@mail.gmail.com>
- In-Reply-To
- <20110427113840.GF31730@paksenarrion.iveqy.com>
On Wednesday, April 27, 2011, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
Show 25 quoted lines
> On Wed, Apr 27, 2011 at 03:33:57PM +1000, Jon Seymour wrote:
>> So, I think at a very minimum, a plugin architecture should specify
>> the file system layout of packages to be managed by a plugin/package
>> manager.
>
> As I recall, Junios initial plan was to have gitk-git as a submodule at
> some point. I still thinks this is a good idea.
>
> If we extends the submodule concept, of not only having a list of
> submodules, but also state weather a submodule is 'active' or 'inactive'
> we could easily get a _very_ customable git.git.
>
> Imagine git.git only containing git. A 'git submodule init' would load
> the default 'active' submodules (for example git-gui, gitk-gui and
> gitweb), everything in contrib is 'inactive'. The point here is to be
> able to ship references to nice things to have (contrib) but not force
> the use (download, diskspace, etc.) of it.
>
> If a user finds an other awesome "plugin" to use with git, it's easy to
> add it to h{er,i}s repository with 'git submodule add'.
>
> Once the code is downloaded to the git-workspace (via 'git submodule
> update') the git build system ('make') would take care of building and
> installation, just as it does today.
>Frederiick,
I have also been think about submodules as one possible back-end package distribution manager, It certainly makes sense since once can at least assume git is available :-)
However, it would be only one way, precisely because I will need to rely on real package managers tif he build step is non-trivial.
Anyway, thanks for your feedback.
Jon.
Show 7 quoted lines
> -- > Med vänliga hälsningar > Fredrik Gustafsson > > tel: 0733-608274 > e-post: iveqy@iveqy.com >