# What is the best way to add a theme to your repo?
**URL:** https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296
**Category:** support
**Created:** [June 5, 2018, 3:23pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296 "2018-06-05T15:23:35Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@gaetawoo](https://discourse.gohugo.io/u/gaetawoo)
#### Post date: [June 5, 2018, 3:23pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/1 "2018-06-05T15:23:35Z")
One could do a _submodule_, or a _clone_, or just copy the files and not the repo…
What are the pros and cons of each option?
UPDATE: also _subtree_ as shared by @bep
Looks like this is a repeat question of this previous post:
> [@Adding a theme as a submodule or clone?](https://discourse.gohugo.io/t/adding-a-theme-as-a-submodule-or-clone/8789):
>
> In [https://gohugo.io/themes/installing-and-using-themes/](https://gohugo.io/themes/installing-and-using-themes/) it is suggested to add them with git clone: git clone https://github.com/spf13/hyde While in [https://gohugo.io/getting-started/quick-start/#step-3-add-a-theme](https://gohugo.io/getting-started/quick-start/#step-3-add-a-theme) it uses git submodule: git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\ What are the pros and cons of each method or what has been your experience with using each of them?
---
### Author:  [@budparr](https://discourse.gohugo.io/u/budparr)
#### Post date: [June 5, 2018, 7:31pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/2 "2018-06-05T19:31:36Z")
I use submodules. That way you can easily update your theme to the latest version, yet the version you have is fixed at a particular time (based on commit)
---
### Author:  [@bep](https://discourse.gohugo.io/u/bep)
#### Post date: [June 5, 2018, 7:35pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/3 "2018-06-05T19:35:58Z")
> [@gaetawoo](#):
>
> One could do a _submodule_ , or a _clone_ , or just copy the files and not the repo…
You can also add it as a git subtree – which I would only recommend in some special cases, but I thought I would add it for completeness. If you start in the hugo repo, you see it in action: hugo/docs is a sub tree which also has the theme as a subtree. One of the benefits of this is that we get a full source distribution incl. docs and theme when we do releases.
But in general, I would recommend submodules. Then you can pull in updates with:
````auto
git submodule update --remote --merge
```
````
---
### Author:  [@gaetawoo](https://discourse.gohugo.io/u/gaetawoo)
#### Post date: [June 5, 2018, 7:44pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/4 "2018-06-05T19:44:00Z")
Thanks @bep and @budparr. What if you’ve made changes to your theme that you don’t want to push back to the theme as a PR and you don’t want your local changes to be overwritten by updating your theme (via a submodule)? And when you push your website repo to github you want your changes there along with the rest of the theme you were working with.
---
### Author:  [@gaetawoo](https://discourse.gohugo.io/u/gaetawoo)
#### Post date: [June 5, 2018, 8:27pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/5 "2018-06-05T20:27:35Z")
After some extensive duckduck-fu, I came across this as what I imagine would answer my question?:
> From your question it seems that your submodule (say proj-dep) is technically an external library.
>
> Let us say that the code of proj-dep is hosted at [https://github.com/vendor/proj-dep](https://github.com/vendor/proj-dep) and you have mapped this path to your submodule.
>
> However, you are not simply using proj-dep as is, you are using a modified version of the same.
>
> You should be creating your own fork of [https://github.com/vendor/proj-dep](https://github.com/vendor/proj-dep) to [https://github.com/alex/proj-dep](https://github.com/alex/proj-dep) and map this second path to your submodule.
>
> You will be able to push your own changes to this fork. Also, you can pull changes from vendor’s proj-dep as and when needed and merge/rebase your fork (eventually pulling them down to your submodule path).
Accurate? Sound like exactly what I’m talking about. Updating the fork with the master would have to happen in/on Github though right? Since the fork is a product of Github, not git or my local repo.
---
### Author:  [@budparr](https://discourse.gohugo.io/u/budparr)
#### Post date: [June 5, 2018, 10:42pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/6 "2018-06-05T22:42:57Z")
I don’t think so. It’s all Git - has nothing to do with Github, necessarily. Atlassian has some good material on submodules. If you have things you’ve done to the theme that would get overwritten updating the submodule, you’ll need to put those into your local root (or maybe oneday a second theme 🙂 ).
---
### Author:  [@gaetawoo](https://discourse.gohugo.io/u/gaetawoo)
#### Post date: [August 22, 2018, 1:50am UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/7 "2018-08-22T01:50:01Z")
Is there any benefit or best practice between the following two methods:
1. Forking a theme and adding your fork as a submodule, which you then edit directly as needed. If the upstream theme updates, you can pull in those changes to your fork.
or
2. Simply adding the theme directly as a submodule and any changes you want to make to the theme you do so by adding them to your hugo site’s own layout directory. This will take precedence over the submodule’s version.
1 keeps things all in their place but seems maybe a little overcomplicated. 2 means you have theme files in two places but simplifies the structure…
🤷♂️
---
### Author:  [@jhabdas](https://discourse.gohugo.io/u/jhabdas)
#### Post date: [August 22, 2018, 7:33am UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/8 "2018-08-22T07:33:50Z")
One of the cool things about the inheritance model used by the lookup order is it may be combined with block layouts. Blocks give you the power to compose layouts so you can override specific pieces of content without carrying around a lot of custom-extended base theme code and makes it easier to pivot between the various possible update methods.
As for the _best_ way, that’s fairly subjective. In my mind the best way would be the one with the least opinion and minimal amount of dependencies (read: `git`, the hidden dependency in some themes, which makes them less portable and harder to grok).
---
### Author:  [@gaetawoo](https://discourse.gohugo.io/u/gaetawoo)
#### Post date: [August 23, 2018, 3:44am UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/9 "2018-08-23T03:44:42Z")
forgive me but i’m not sure I follow either paragraph. would you mind explaining just a bit more?
---
### Author:  [@TotallyInformation](https://discourse.gohugo.io/u/TotallyInformation)
#### Post date: [August 23, 2018, 6:04am UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/10 "2018-08-23T06:04:47Z")
> [@gaetawoo](#):
>
> orking a theme and adding your fork as a submodule, which you then edit directly as needed. If the upstream theme updates, you can pull in those changes to your fork.
> or
This allows you full control while maintaining backups for security. Remember that, while GitHub does not provide private repos on the free tier, others like GitLab **do**. So you can keep your amended theme private if you like but still get the benefits of a cloud backup.
---
### Author:  [@gaetawoo](https://discourse.gohugo.io/u/gaetawoo)
#### Post date: [August 23, 2018, 3:28pm UTC](https://discourse.gohugo.io/t/what-is-the-best-way-to-add-a-theme-to-your-repo/12296/11 "2018-08-23T15:28:10Z")
True, and I see others who fork themes will add their own changes to their fork, which wouldn’t be visible if they were making their changes within the site’s layout folders.