.GitInfo and `fetch-depth` when using host GUI

When using a GitHub Action (GHA) to publish my site, I know (thanks to an old thread on this Discourse) to specify fetch-depth: 0 in the branch checkout so that my use of .GitInfo will produce the desired result: mainly, page-specific .Lastmod and GitInfo.Hash data. However, if I use a host’s native GUI instead of a GHA, this data is from the site’s most recent commit, rather than the page’s. Since I’m using a partial to get this data for the page, that means every page using the partial is showing that data.

I have seen this behavior in tests of the GUIs for Cloudflare Pages, Netlify, and Vercel — and, to my knowledge, other Hugo sites publish via their hosts’ GUIs yet seem to get per-page .GitInfo data. Also, neither the documentation nor my search for more info, much less my examination of other Hugo sites’ repos when those are viewable, leads me to think that those folks are doing anything special to achieve these results (which is especially odd to me given that it appears hosts are specifying fetch-depth at higher numbers, such as 2 for Vercel). Thus, I don’t know why my site must use a GHA to get truly per-page .GitInfo data.

My .GitInfo-specific code is the following partial, which provides the title sections of nearly all of my pages:

Thanks in advance for helping me understand where/how/whether I’m doing this wrongly.

I figured out a somewhat (?) hacky way to resolve this:

Hi, Bryce. In this article, you advise not to include the script in our build command, but I’ve successfully implemented this solution proposed by @jmooring and it’s working fine on my site deployed by Netlify

1 Like

@alcarazr Thanks. I’ve seen that before, but note the person’s original request to which @jmooring was replying:

Unlike the current system, I don’t want this to be specific to a certain page, I just want the latest commit in my current branch to be shown.

On the other hand, what I wanted was to display Git information that was specific to each page. Of course, quite a few folks prefer the last-commit-wherever approach that the other person requested, so that’s absolutely fine — whatever meets one’s specific needs. :slight_smile:

The thing is that I’m using that approach to show my latest commit on the branch (see the end of this line), but also showing the latest commit of a specific page with this. See this example page. Above I have the latest specific edit and below on the footer I have the very latest commit on my site. All deployed by Netlify using this build command, using this script.

1 Like

Thanks; interesting info!

Perhaps Netlify allows deeper fetching than Vercel (fetch-depth: 10), where I spent the most time testing this — and, as I explained, I had no luck period with the Cloudflare Pages UI, so I couldn’t verify anything there. I will update my post accordingly as I learn more.

1 Like

Does Netlify have any documentation about fetch depth? That would be Very Useful Information.

What I’ve found is primarily anecdotal in various Netlify discussions and issues, but no flat statement thereof as in the Vercel docs.


It’s a few months old, but seems to indicate that Netlify does not perform a shallow clone.

1 Like

Yes, that was one of the issues I saw, and I agree.

Also, based on the comments from @alcarazr, I just tried a straight deployment to Netlify without using my alternative method and, indeed, it appears to be a complete clone or at least a very deep one; all the Git commit data straight from .GitInfo is accurate. So, apparently, I’ll need to revise my post to note that this is more of a host-agnostic approach but that not all hosts need it, depending on their individual fetch-depth settings — which i probably should’ve concluded in the first place. :person_shrugging:

You might also include a note about performance when using git log. It bites.

1 Like

Have updated my post accordingly. Also was able to determine the following through further testing:

  • Cloudflare Pages and Render do shallow clones, as does Vercel.
  • The alternative procedure I described works on those hosts, too; previously had been able to test it only on Netlify (which, as I now know, doesn’t need it because it apparently does deep clones) and Vercel.

Tried to test on DigitalOcean’s Apps Platform, as well, but that host’s GUI has gotten awfully “grabby” (throwing “plans” at you and the like) since I last tried it, so I aborted the attempt.

Did not try GitHub Pages or GitLab Pages.

GitHub’s starter workflow for Hugo has:

- name: Checkout
  uses: actions/checkout@v3
    submodules: recursive

actions/checkout@v3 has:

# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''

So you would need to change the “starter workflow” to:

- name: Checkout
  uses: actions/checkout@v3
    submodules: recursive
    fetch-depth: 0

The Hugo documentation for GitHub hosting already has:

- uses: actions/checkout@v3
    submodules: true  # Fetch Hugo themes (true OR recursive)
    fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod
1 Like

My GitLab workflow file (.gitlab-cy.yaml) has:

  HUGO_VERSION: 0.109.0

I don’t remember if the GIT_DEPTH was in a default workflow, or if I added it when deploying the first time.

1 Like

Oh, right; very good points.

Come to think of it, both GHP and GLP obviously depend on CI/CD, so there wouldn’t have been any point in my testing either in the first place. That is, the whole point was to get the good data with the non-CI/CD build process touted by the other hosts I mentioned, since — as you showed — it’s easy to specify the fetch-depth with either.

The underlying concern was documented at some point, then it evaporated:

PR welcome.

1 Like

Definitive answer from Netlify.

Our clones are not shallow but we do perform a blobless clone which makes it even faster.


That’s extremely interesting! Thanks for asking them.

Blobless clones seem to be the best solution for deployment, not sure why only Netlify does that :man_shrugging:. I was thinking about moving to Cloudflare Pages (starting to have bandwidth concerns with Netlify) but this is something to consider :thinking:.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.