Support GitInfo for content folders in different Git repositories

[deanishe]

GitInfo provides metadata about content files, but from my observations and reading of the code, it actually searches the working directory for a git repo, not the content directory.

As a result, if content and theme/configuration are kept in separate repos (including when content is a submodule), Hugo fails to find any git metadata for the content files because it's querying the wrong repo.

Because GitInfo is for information about content, not theme/build configuration etc., Hugo should search for a git repo from the content directory, not the working directory, which is generally where the configuration and themes are found, and may or may not be in the same repo.

This should make GitInfo behave correctly for anyone who keeps their content in a separate repo, while continuing to work as before for mono-repos.

[bep]

Hugo should search for a git repo from the content directory

That is a bold statement. 99% of Hugo sitest out there are mono repos with a /content folder and possibly a theme added as a Git submodule. I much prefer to support the 99% than the 1%.

[deanishe]

It wouldn't affect those 99%, though, would it? If the content directory is just a regular subdirectory of the repo, Hugo's going to find the exact same repo root.

But GitConfig would also work for people who don't keep config+content in the same repo.

[bep]

It wouldn't affect those 99%, though, would it?

Maybe, maybe not.

[deanishe]

Maybe, maybe not.

How could it break anything that currently works? It'd just mean running git rev-parse --show-cdup in a subdirectory of the current one.

[deanishe]

Submitted the above PR. I don't really understand why I'm getting errors on Travis regarding #5327. Is that something I've broken? Did I pull the wrong branch? I'd be grateful for any input, as I'm totally new to the Hugo codebase.

Regarding the patch:

From my tests, the TL;DR is it works 100% the same in the common "mono-repo" scenario, also enables the standard cd /my/site && hugo build method when content is in a different repo (submodule or otherwise), but totally breaks (build error) an --enableGitInfo build scenario that currently half works (no build error, but GitInfo isn't actually working).

Specifically, if you currently run hugo with --enableGitInfo from within a repo but using content that isn't in any repo, the build succeeds because Hugo is looking for metadata in the site repo. With the patch, the build fails because Hugo recognises that the content isn't in a git repo.

Currently, --enableGitInfo only works correctly if hugo is run in the content's repo. This works great in a site+content mono-repo, but if content is in a separate repo, you have to cd to it to get GitInfo to work correctly, and therefore pass --config=/XYZ/config.toml, --themesDir=/XYZ/themes etc. to the hugo command.

This patch makes the cd /my/site && hugo workflow Just Work™ for folks who would like to keep their content in a separate repo, but also use the extremely awesome GitInfo feature.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[deanishe]

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

Because the GitInfo feature, which provides content metadata, currently doesn't actually consider the content directory at all. It looks in the working directory instead, and only works correctly if the content directory is in the same git repo as the working directory.

The core Hugo application does not impose any restrictions on the location of the content directory (relative to where the hugo command is being run). You just need to specify the appropriate flags.

The GitInfo does not work that way, however. It completely ignores the --contentDir flag and searches for git metadata for the site content based on the working directory instead of the directory where the site content is actually located.

While this has always been the default behaviour, it's also quite obviously incorrect to search for content metadata starting from the working directory instead of the directory where the files whose metadata you're interested in are actually located.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[deanishe]

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

Hugo still tries to find the content's git repo in workingDir, not contentDir.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[deanishe]

As above. Hugo still looks for content metadata in a directory where they may or may not be, instead of the one they definitely are in.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[deanishe]

As above. Hugo still looks for content metadata in a directory where they may or may not be, instead of the one they definitely are in.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[deanishe]

Bad bot.

[Jcahilltorre]

Hi, We are using modules in our documentation so that different product teams can keep their documentation in separate repos. When trying to add the "last updated" information into our documents we are encountering the issue mentioned here.

Are there any updates or plans to implement the changes mentioned above by deanish to the main branch? Anything you can share with us? Thanks

[retifrav]

We are using modules in our documentation so that different product teams can keep their documentation in separate repos

We have (almost?) exactly the same case. We have a dedicated repository with "base" Hugo things, such as theme, layouts, partials, shortcodes, styles, etc, and then several different projects include this repository as a Git submodule in their repositories, and each have their own content folder with the actual Markdown content one level up, so the folders structure is like this (simplified):

├── base # Git submodule with common Hugo stuff
│  ├── archetypes
│  │   ├── ...
│  └── themes
│      └── ourTheme
│          ├── assets
│          │   ├── ...
│          ├── layouts
│          │   ├── ...
│          ├── static
│          │   ├── ...
│          └── theme.toml
├── config.toml
└── content
   ├── _index.md
   ├── here
   │   ├── ...
   ├── goes
   │   ├── ...
   ├── the
   │   ├── ...
   ├── actual
   │   ├── ...
   └── content
       ├── ...

And so Hugo is run like this:

$ cd base
$ hugo --config="../config.toml" --contentDir="../content/"

That is such a killer feature of Hugo's flexible architecture to be able to work like that, but unfortunately this way it indeed doesn't get Git information from the project repository, where the actual useful content lives.

It would be great if Hugo was using Git information from the repository which the content folder belongs to, or perhaps if there was an option like --gitInfoPath="/path/to/repository".

[colinwilson]

Does anyone have a workaround/link for fetching git data when the content dir is a submodule?

[nathlaroche]

Hi, We are using modules in our documentation so that different product teams can keep their documentation in separate repos. When trying to add the "last updated" information into our documents we are encountering the issue mentioned here.

Are there any updates or plans to implement the changes mentioned above by deanish to the main branch? Anything you can share with us? Thanks

We are running into this exact same issue. Hugo modules are very effective in exactly the situation described above, but because the Last modified date is useless in these sub modules, we are removing it from the doc.

Would love, love, love to see a fix for this! :)

[magicwenli]

Looking for a solution for this too.

Would love, love, love to see a fix for this! :)

[siddhpant]

Bump. This is such a crucial feature. I want to have content and config separate from each other, as it should be. They are not dependent on each other.

[siddhpant]

Currently, --enableGitInfo only works correctly if hugo is run in the content's repo. This works great in a site+content mono-repo, but if content is in a separate repo, you have to cd to it to get GitInfo to work correctly, and therefore pass --config=/XYZ/config.toml, --themesDir=/XYZ/themes etc. to the hugo command.

@deanishe Can you tell how? I have content/ folder initialised as a repo and have gitignored it in the root.

If I run hugo server --config=../config.toml --themesDir=../themes -c . -l ../layouts/ from content/ dir, the GitInfo is still empty.

[cgglyle]

Currently, --enableGitInfo only works correctly if hugo is run in the content's repo. This works great in a site+content mono-repo, but if content is in a separate repo, you have to cd to it to get GitInfo to work correctly, and therefore pass --config=/XYZ/config.toml, --themesDir=/XYZ/themes etc. to the hugo command.

@deanishe Can you tell how? I have content/ folder initialised as a repo and have gitignored it in the root.

If I run hugo server --config=../config.toml --themesDir=../themes -c . -l ../layouts/ from content/ dir, the GitInfo is still empty.

Hi @siddhpant I'm use this command: hugo server --configDir="../config/" --themesDir="../themes/" --contentDir="." This is worked!

This is my dir tree

.
├── assets
├── config
│   └── _default
├── content
└── themes