develooper Front page | perl.perl5.porters | Postings from August 2009

Re: The plan for ext/ and dual-life modules

Thread Previous | Thread Next
From:
Sam Vilain
Date:
August 30, 2009 14:52
Subject:
Re: The plan for ext/ and dual-life modules
Message ID:
4A9AF48F.9050309@vilain.net
demerphq wrote:
>>> I tend to prefer git-subtree, but it's only because I've heard bad
>>> things about submodules.
>>>       
>> I think most of the criticism is due to the fact that submodules are
>> not what people expect them to be. People tend to be deterred by the
>> fact that every time you update a submodule you need to commit to the
>> parent.
>>     
>
> That doesnt make me feel all warm and fuzzy frankly.
>   

However, it does mirror current practice; development on modules
generally continue separately and out of band to perl; and then you have
commits which update the version in blead etc to the latest version of
the module.

>  Submodules to me
> still seem to be too unstable for us.
>
> I mean, we have a mostly git-unaware/novice user base, submodules seem
> to fox experienced users regularly. Using them for our community seems
> to me  to be asking for trouble.
>
> Beside that they are cool and froody, whats the advantage? Especially
> given that our Dual-lifed modules arent necessary vc-ed under git
> anyway, whats the advantage of a submodule /at all/ in our case?
>   

Submodules have one advantage over sub-tree merging, in that the history
of the submodule, which generally will be of little interest to people
working with perl.git, will be stowed away inside the submodule.  with
git-subtree, it's basically another branch so you'll end up with commits
on the sub-project intermingled with the main commit graph.

Another advantage of submodules vs the current system it is that the
module author does not need to do anything; they just make their source
code available.  If it is not in git, it can be tracked/imported (I have
registered the 'cpan' github account should someone want to take up such
a project), and then used as a submodule.

The only real disadvantage is an extra step after clone required to
populate the submodules.  Also, it is possible to end up pushing stuff
no-one can clone if you are not careful.  But these problems can be
solved by supplying a script to populate the submodule directories if
not present, and set up a safety hook (see
http://marc.info/?l=git&m=124140813023956&w=2 for the basic idea).  This
can be called by the make/Configure process when building from a git source.

Submodules are by no account "unstable"; the merged implementation was
the third generation and is very solid, and like the rest of git
understanding follows quickly from knowing how it fits with the git basics;

  - in the tree object, instead of a tree or a blob, you have a "commit"
SHA1
  - /.gitmodules has the URL corresponding to that path
  - objects for the submodule are stored separately under submodule/.git
  - the submodules only change commit when you tell them to
  - with the commit checked out that you want, 'git add' the submodule
like a regular file

Of course the man pages and tutorials will go into more detail, but
there is a very simple overview.

Sam

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About