You just have to define a custom README.md.gotmpl without the {{ template "helm-docs.versionFooter" . }} part.

You just have to define a custom README.md.gotmpl without the {{ template "helm-docs.versionFooter" . }} part.

Why not to have just a flag to turn it off?

You just have to define a custom README.md.gotmpl without the {{ template "helm-docs.versionFooter" . }} part.

Why not to have just a flag to turn it off?

Because that's an anti-pattern. If you start going down the path of "we need a CLI flag / toggle for every single feature" you run into something very complicated, very quickly. It's much better from a practical, and maintainability perspective, if you cover most of the use cases that people want, and template the rest. If you want to see where the road you desire leads to, look no further than the git CLI. Most people avoid any sort of interaction with that if possible because it has too many options.

If you install this tool with "Go" this field is absent. Means that it is inconsistent. Better off having a simple flag for this field because when you generate new helm-docs with the new version tool mostly you have is just a different footer.
It's only for a user convenience especially when you have helm-docs diff checks at the server side.

You just have to define a custom README.md.gotmpl without the {{ template "helm-docs.versionFooter" . }} part.

that would actually clutter the repository where I need to copy-paste the same template just to get rid of the final signature.

It's really useful to know which is the exact version on which a README has been generated? The most simple solution for me is just to get rid of the version e.g.

Autogenerated from chart metadata using [helm-docs](https://github.com/norwoodj/helm-docs)

The problem isn't that the autogenerated message is there. The problem is that the autogenerated message changes gratuitously from the point of view of a chart developer.

If I'm contributing to a chart in a repo and the repo is using pre-commit, and I change a values file in a way that does not lead to docs that are different, then it is a violation of the principle of least astonishment for there to be an update to README.md that contains only the updated footer.

Similarly, if my PR validation checks to make sure that all helm-doc is up-to-date, I wouldn't expect it to fail just because there's a version difference between CI's helm-docs and the helm-docs that initially generated the README.

Granted, we can get around this with a custom template. But it would be really nice for this process to work out-of-the-box.

I would rather have the go install consistent

If you install using go install it is excluding the footer
yet the docker image and the release archive will create the footer