Support GitInfo for content folders in different Git repositories #5533

deanishe · 2018-12-17T17:58:10Z

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.

The text was updated successfully, but these errors were encountered:

bep · 2018-12-17T18:01:44Z

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 · 2018-12-17T18:04:51Z

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 · 2018-12-17T18:13:39Z

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

Maybe, maybe not.

deanishe · 2018-12-17T18:28:29Z

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.

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533

deanishe · 2018-12-18T20:17:57Z

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.

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533

stale · 2019-04-17T20:31:25Z

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.

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533

deanishe · 2019-04-17T22:48:52Z

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.

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533

stale · 2019-08-15T23:22:25Z

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.

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533

deanishe · 2019-08-16T07:50:10Z

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 · 2019-12-14T08:38:33Z

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.

Add an option to get git metadata from the content dir instead of the working dir Fixes gohugoio#5533

stale · 2020-04-12T11:06:18Z

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.

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533

deanishe · 2020-04-13T06:42:55Z

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 · 2020-08-16T08:27:04Z

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 · 2020-08-16T16:10:12Z

Bad bot.

Add an option to get git metadata from the content dir instead of the working dir Fixes gohugoio#5533 Signed-off-by: Khusika Dhamar Gusti <[email protected]>

Jcahilltorre · 2021-06-21T15:44:46Z

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 · 2021-07-13T17:23:49Z

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".

When the last modified date of a page cannot be determined, i.e. due to this missing feature in Hugo, do not show that template in the page footer. See gohugoio/hugo#5533 Signed-off-by: Carolyn Van Slyck <[email protected]>

colinwilson · 2022-10-17T21:04:49Z

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

nathlaroche · 2022-11-16T15:45:09Z

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! :)

wesleyel · 2023-01-02T08:19:01Z

Looking for a solution for this too.

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

Get metadata for `GitInfo` from `contentDir` instead of `workingDir`. This decouples the `GitInfo` feature from the working directory, making it dependent on configuration, not the directory `hugo` is run in. Rationale --------- This patch aligns the `GitInfo` feature more closely with the way the rest of Hugo works. The standard `cd /my/site && hugo` build idiom also works when content isn't in the same repo as site, and it allows the `GitInfo` feature to be used regardless of which directory `hugo` is run from (when configured correctly), as is the case for other features. Currently, Hugo searches the working directory for the git repo to populate `GitInfo` content metadata. This means that, in order to retrieve the correct metadata, `hugo` must be run from within the repo containing the content. If `hugo` isn't run from within a repo, `--enableGitInfo` causes a repo-not-found build error, even if the content *is* in a repo. And if `hugo` is run in a different repo, say if content is a submodule of site, it will find no/bad data, as it's looking in the wrong repo. This restriction is unique to `GitInfo` (AFAIK). If you aren't using that feature, you can run Hugo in any directory you want, as long as you pass the appropriate flags. This patch makes it possible to use the standard `cd /my/site && hugo` build process also when the content is in a different repo. More generally, it makes it possible to run `hugo` from any directory when using `--enableGitInfo`, as you can when not using it. Effects ------- `GitInfo` currently only works correctly if `workingDir` and `contentDir` are in the same repo, so it will continue to work everywhere it already works, particularly in the normal case of having site and content in a single repo. This patch will also make `GitInfo` Just Work ^(TM) when content is in a separate repo to the site. Currently, using `GitInfo` requires `cd`-ing to the content repo and running `hugo` from there with a bunch of flags. If the content is unversioned, this patch will cause Hugo to *always* fail to build the site when run with `--enableGitInfo`. Currently, because Hugo looks in the working directory, not the content directory, a build with unversioned content can succeed when Hugo is called with `--enableGitInfo` as long as Hugo is *run* within a git repo. Hugo won't find any (correct) file metadata, but missing file metadata don't cause a build error, whereas a missing git repo does. Fixes gohugoio#5533 Signed-off-by: Khusika Dhamar Gusti <[email protected]>

siddhpant · 2023-05-21T12:17:43Z

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 · 2023-05-21T12:29:31Z

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 · 2024-01-04T02:43:08Z

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

bep changed the title ~~GitInfo looks in working directory, not content directory~~ Support GitInfo for content folders in different Git repositories Dec 17, 2018

bep added the Enhancement label Dec 17, 2018

deanishe mentioned this issue Dec 17, 2018

Retrieve GitInfo from contentDir #5535

Closed

stale bot added the Stale label Apr 17, 2019

stale bot removed the Stale label Apr 17, 2019

stale bot added the Stale label Aug 15, 2019

stale bot removed the Stale label Aug 16, 2019

stale bot added the Stale label Dec 14, 2019

asafg6 added a commit to asafg6/hugo that referenced this issue Jan 28, 2020

tpl: Support GitInfo for content folders

9735069

Add an option to get git metadata from the content dir instead of the working dir Fixes gohugoio#5533

stale bot added the Stale label Apr 12, 2020

stale bot removed the Stale label Apr 13, 2020

stale bot added the Stale label Aug 16, 2020

stale bot removed the Stale label Aug 16, 2020

bep added the Keep label Aug 16, 2020

SirUli mentioned this issue Nov 3, 2020

Content mounted via modules does not have a "GitInfo" #7922

Closed

khusika pushed a commit to khusika/hugo that referenced this issue Mar 19, 2021

tpl: Support GitInfo for content folders

b87be30

Add an option to get git metadata from the content dir instead of the working dir Fixes gohugoio#5533 Signed-off-by: Khusika Dhamar Gusti <[email protected]>

carolynvs mentioned this issue Jul 13, 2021

Do not show page modified when empty cncf/tag-contributor-strategy#118

Merged

y1450 mentioned this issue Jun 30, 2022

Last modified is not shown on Uppercase files jackyzha0/quartz#151

Closed

bep added this to the v0.131.0 milestone Jul 30, 2024

bep modified the milestones: v0.131.0, v0.133.0 Aug 9, 2024

bep modified the milestones: v0.133.0, Unscheduled Aug 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support GitInfo for content folders in different Git repositories #5533

Support GitInfo for content folders in different Git repositories #5533

deanishe commented Dec 17, 2018

bep commented Dec 17, 2018

deanishe commented Dec 17, 2018 •

edited

Loading

bep commented Dec 17, 2018

deanishe commented Dec 17, 2018

deanishe commented Dec 18, 2018

stale bot commented Apr 17, 2019

deanishe commented Apr 17, 2019

stale bot commented Aug 15, 2019

deanishe commented Aug 16, 2019

stale bot commented Dec 14, 2019

stale bot commented Apr 12, 2020

deanishe commented Apr 13, 2020

stale bot commented Aug 16, 2020

deanishe commented Aug 16, 2020

Jcahilltorre commented Jun 21, 2021

retifrav commented Jul 13, 2021 •

edited

Loading

colinwilson commented Oct 17, 2022

nathlaroche commented Nov 16, 2022

wesleyel commented Jan 2, 2023

siddhpant commented May 21, 2023

siddhpant commented May 21, 2023

cgglyle commented Jan 4, 2024

Support GitInfo for content folders in different Git repositories #5533

Support GitInfo for content folders in different Git repositories #5533

Comments

deanishe commented Dec 17, 2018

bep commented Dec 17, 2018

deanishe commented Dec 17, 2018 • edited Loading

bep commented Dec 17, 2018

deanishe commented Dec 17, 2018

deanishe commented Dec 18, 2018

stale bot commented Apr 17, 2019

deanishe commented Apr 17, 2019

stale bot commented Aug 15, 2019

deanishe commented Aug 16, 2019

stale bot commented Dec 14, 2019

stale bot commented Apr 12, 2020

deanishe commented Apr 13, 2020

stale bot commented Aug 16, 2020

deanishe commented Aug 16, 2020

Jcahilltorre commented Jun 21, 2021

retifrav commented Jul 13, 2021 • edited Loading

colinwilson commented Oct 17, 2022

nathlaroche commented Nov 16, 2022

wesleyel commented Jan 2, 2023

siddhpant commented May 21, 2023

siddhpant commented May 21, 2023

cgglyle commented Jan 4, 2024

deanishe commented Dec 17, 2018 •

edited

Loading

retifrav commented Jul 13, 2021 •

edited

Loading