Search

Anyone here have experience with or using git subtrees? From what I can gather from Google, it seems like subtrees are basically like submodules except they actually put the code in your repo, thus obviating the need to do git submodule init and git submodule update. It also seems like it would eliminate the need to do those processes on the production server as well.

A tree object represents one level of directory information. It records blob identifiers, path names, and a bit of metadata for all the files in one directory. It can also recursively reference other (sub) tree objects and thus build a complete hierarchy of files and subdirectories.

Loeliger, Jon; McCullough, Matthew (2012-08-15). Version Control with Git: Powerful tools and techniques for collaborative software development. O'Reilly Media.

Based on what you're saying, you would just include the 'core' extensions in the main download. That may be what they're planning. See this.

I'm not sure if you understood my post, or I'm just not understanding your reply?

DESCRIPTION
-----------
Subtrees allow subprojects to be included within a subdirectory
of the main project, optionally including the subproject's
entire history.

For example, you could include the source code for a library
as a subdirectory of your application.

Subtrees are not to be confused with submodules, which are meant for
the same task. Unlike submodules, subtrees do not need any special
constructions (like .gitmodule files or gitlinks) be present in
your repository, and do not force end-users of your
repository to do anything special or to understand how subtrees
work. A subtree is just a subdirectory that can be
committed to, branched, and merged along with your project in
any way you want.

They are also not to be confused with using the subtree merge
strategy. The main difference is that, besides merging
the other project as a subdirectory, you can also extract the
entire history of a subdirectory from your project and make it
into a standalone project. Unlike the subtree merge strategy
you can alternate back and forth between these
two operations. If the standalone library gets updated, you can
automatically merge the changes into your project; if you
update the library inside your project, you can "split" the
changes back out again and merge them back into the library
project.

For example, if a library you made for one application ends up being
useful elsewhere, you can extract its entire history and publish
that as its own git repository, without accidentally
intermingling the history of your application project.

@Pat, the git subtree feature looks very interesting. I hadn't heard of it before. Thanks for pointing it out.

It also sounds very complex and verbose to implement:

Although, a .gittrees configuration file promises to make the process a little less verbose:

It sounds like the idea is relatively new, and the dust hasn't quite settled on how the configuration file feature is to be implemented in Git.

Yeah it seems like git subtree is not documented or supported very well, which makes me hesitant to use it.

I am also considering using Composer as it has come up several times in my Google searches, and I've seen it on the AWS forums as an alternative to submodules. Has anyone used it before with good results?

I've secretly had my eye on the Git Subtree pattern for a while, and yes it is quite new.

I would be hesitant to include it in the project at this early stage. Submodules never worked very easily and caused (still causes) a lot of headaches if done incorrectly.

That being said, when it matures a bit, it would be a great way to manage our extension dependencies better than submodules, at least for the 2.x branch of the project.

When the new Symphony project kicks off and has code to show, it will be composer based with a full package download for those without composer access, so it would be a little bit useless then.

We shall see what happens :)

@designermonkey: That sound awesome for the future.

I guess for now, I will be migrating all my submodules to Composer packages. I tried, and it does work (extension files are downloaded and copied into my project). There will just be conflicts when I update my project and the Symphony repo tries to bring back the submodules. There are also some extra junk like the composer folder and autoload.php.

For anyone interested in how to set it up, this is my composer.json file (note the custom vendor directory for extensions and custom repo and package definitions):

{
    "name": "pat/coolproject",
    "description": "This is a cool project",
    "homepage": "http://cool.com",
    "config": {
        "vendor-dir": "extensions"
    },
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "s3upload_field",
                "version": "dev-master",
                "source": {
                    "url": "https://github.com/symphonists/s3upload_field",
                    "type": "git",
                    "reference": "master"
                }
        }
    }],
    "require": {
        "s3upload_field": "dev-master"
    }
}

Sweet. Thanks @pat :D

I was looking for quite a while for a solution to this issue.

BTW Symphony doesn't like that Composer creates the directory extensions/composer/ with a bunch of crap in it. To fix this, just add an empty file at extensions/composer/extension.driver.php to satisfy Symphony.

@Pat - Thanks for sharing about Composer. That's a great idea. How is it working for you so far?

Works great so far. It's much easier to add and remove extensions. With git submodules, there's no official way to remove a submodule, which led to many git errors for me.

From browsing around, it also seems like every PHP framework uses Composer. Maybe Symphony Next should consider using Composer as an extension manager.

Amazon Elastic Beanstalk also works perfectly with Composer. It makes deploying Symphony a breeze :)

@Pat - That's awesome! One day, if time allows, would you have time to do a quick write up or even a screencast showing how you set that up? I think it would be a great learning opportunity for many... including myself.

Thanks again for sharing.

Thanks @Pat. This is really useful stuff and fantastic to know that both Git Subtree's and Composer can be incorporated successfully.

I haven't yet tried out Amazon Elastic Beanstalk but it's quite a significant addition to their product suite and one which finally makes it more feasible to host with AWS. As @bzerangue mentioned I'd be interested in any info on the setup.

Sure, I'll put it on my todo list.

As for my Elastic Beanstalk setup, there isn't much to setup. You set it up from the command line in your git project. It's very easy. No need to configure the server itself, just select PHP 5.4 as your application type. Best of all, the micro level of AWS services is all free, so you can test and develop before launch without paying. I haven't launched my project yet, but EB is supposed to auto-scale, so management should be relatively low maintenance.

Just to clarify, I haven't tried out git subtrees yet since there seems to be very little documentation or support.

Word of warning: Elastic Beanstalk's version of Composer does not work with branches other than "master". It will die saying it could not deploy the application. The only solution is to fork the repo and merge the integration or whatever branch into the master branch.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details