Retrieve module from the Git repository

In this example we look at how to check out the STK module from the Git repository.

  1. Go top http://git.magnolia-cms.com.
  2. Search for "standard-templating-kit" with the search tool.
  3. On the results, click modules/standard-templating-kit.git. The project summary is loaded.
  4. Copy the anonymous, read-only URL.
  5. Go to the command line and change to the directory where you would like to have your copy of the Standard Templating Kit project.
  6. Type git clone and paste in the URL. The complete command should will look like this: git clone http://git.magnolia-cms.com/git/modules/standard-templating-kit.git.

Locate module Version

On the project summary on Gitweb site, under the "tags" section, look for the version tag you are interested in (2.0.3 in our example).
If the tag does not show up in the short list, click on "..." at the bottom of the list to reveal the full tag list of this project. Click on the standard-templating-kit-2.0.3 tag. This will give you the details of this 2.0.3-commit

Alternatively, git tag -l will list the tags in your terminal.

Once you know which tag you want, change into the standard-templating-kit directory created by our git clone command above and set the clone back to the desired version using the following command:

git checkout <tag name>

For more details, see the Git usage page.

  • No labels

9 Comments

  1. Natascha Desmarais

    Regarding your question about the reset --hard, you could also simply use git checkout <tag name> (so in this case: git checkout standard-templating-kit-2.0.3). However, this results in a detached head, which is really nothing to worry about if you're just trying to look around in the files.

    You could also create a new branch from that specific tag if you actually want to fiddle around with it. You can use git checkout -b newbranchname standard-templating-kit-2.0.3 for that. This avoids the detached HEAD from the simple tag checkout.

    reset basically just resets your HEAD and index to the specified version without taking care of the working files (unless you use --hard), while checkout is more about the working files (that's why you end up with a detached HEAD in the end).

    So for the sake of what they do and since you're interested in the files more than the rest of the history, I would use the checkout command for that.

  2. Richard Unger

    Thanks for that, Will!

    I've been working on migrating our stuff to 4.5, and the move to Git has been giving me headaches too.

    I'm using the Eclipse EGit plugin, but the procedure is more or less the same. It seems to be a bit easier to browse the tags in EGit, you don't need to mess around with the commit hashes.

    But I can't believe that this is the only way to do this. That's horrible useabilty compared to SVN - why would anyone switch to git, I wonder??

    @Magnolia: really what is missing is a simple way to browse *all* the projects like in SVN, and select individual ones for checkout. Is there no way you can set up your repository so that everything is rooted at one point?

    Richard

    1. Magnolia International

      really what is missing is a simple way to browse all the projects like in SVN, and select individual ones for checkout.

      Not sure what you mean, Richard. Gitweb provides such a flat list, and it's more-or-less duplicated here in the wiki. Or do you mean a way to browse existing repos from EGit ?

      As for reasons for the move, there are many. For me, the main two are

      • branches. branches branches branches. They're just plain impossible to handle in SVN for anything else than version maintenance. Having good branching/merging capabilities will, eventually, when developers get up to speed, help productivity and creativity.
      • "popularity", for lack of a better term. With everyone and their grandmother being on GitHub, Git is becoming ubiquitous, and combined with the branching/merging power, it should become easier to contribute (and for us to review/accept patches!)

      That said, we know it IS hard to switch yourself. Really different mindset. Maybe check these links out:

      It will require some commitment on everyone's part, and I get the feeling from your and a couple of other messages that perhaps we haven't been upfront enough about the move ? In any case, I would advise everyone to try and get familiar with Git with smaller projects, on their own. You don't need a server or anything to get started. In fact, I've started using Git on small projects that currently reside nowhere else than on my laptop, or in some case are still on SVN; I use Git locally before committing larger chunks of work to SVN. git init is all you need !

      1. Richard Unger

        Hi Greg,

        I've been following the move to Git, but this was my first hands-on experience... so I think its just a case of getting used to it.

        So far in my use of Git I've always been able to check out everything I need with a single clone command - smaller projects, I guess.

        You are of course correct that everything is more or less nicely indexed online - I have the page https://git.magnolia-cms.com/gitweb/ permanently open at the moment.

        However, I have not found a way to browse the entire repo with EGit - and that's really what I was complaining about. Magnolia is a big project, and all the modules are split up as many individual Git-Repos. To get everything I need, I have to do many clone operations, each of which involves many "clicks" (or command-line calls, doesn't matter). With SVN, I could browse the whole structure, control-click 17 projects, and check them all out at the same time. Much less work.

        Now the workflow is more like:

        1. Find the module online on the gitweb page, copy the URL.
        2. Paste it into Eclipse, add user and password (each time!)
        3. Wait for everything to clone.
        4. "Checkout" the version I need (luckily EGit makes that easy).
        5. "Import" the project into Eclipse

        So I'm not totally happly with this workflow, but I don't really have a problem with Git itself. I do understand the advantages...

        Anyway, I'm still learning, and I am sure that I'll find a good way to do all this eventually.

        Regards from Vienna,

        Richard

        1. Magnolia International

          You might want to look into Git "modules", that might help.

          1. Richard Unger

            Hi,

            Yes that looks like the right thing: http://git-scm.com/book/en/Git-Tools-Submodules

            If I read this correctly, it would mean that someone (preferably not me (wink) ) could prepare a "meta-project", something like "magnolia-ce-all" and/or "magnolia-ee-all". Within this meta-repository, one would add all the individual git-repos for the various magnolia projects as "submodules". Each submodule would have a directory within the main project.

            After cloning the main project, you would initially just get a set of empty directories. A call to "git submodule update" would fetch all the subprojects in one go, or you could change into specific directories and update them individually.

            Even better, if I understand the documentation correctly, the submodules are linked to specific versions of their projects. So a given version of the main project will include each of its submodules at a given version number. That's really perfect, since this means that (for example) version 4.5.3 of the main project can directly refer to the various versions of the sub-projects that make up magnolia 4.5.3.

            IMHO setting this up would be a good thing, if I've understood everything correctly...

            Regards from Vienna,

            Richard

            1. Magnolia International

              And the cool thing is, you can do this on your own machine (git init to create a new repo), you don't need to push/clone it to/from anyway to get started. If it works well though, I'll be happy to let you push that on our server !

              1. Sven Damm

                Has anybody created these meta projects yet?

  3. Magnolia International

    Note that this clones all versions of the Standard Templating Kit project to your computer, so the process could take some time.

    In the case of STK, the cloning is long, not because it "clones all versions" (tags and branches are cheap in Git, they hardly add anything to the size of the repo), but because it clones all files that ever existed in the repo at some point. Unluckily, the STK repo contained, in its early stages, large images which were later moved somewhere else.

    Try the same with another module, dms for example, and I'm ready to bet just cloning the repo will be faster than checking out just one branch off of svn (wink)