[libvirt PATCH] docs: kbase: Fix the libvirt-host-validate typo
I overlooked this typo during review of 2c3ffa37. Reported-by: Yalan Zhang <yalzhang@redhat.com> Signed-off-by: Erik Skultety <eskultet@redhat.com> --- Pushed as trivial. docs/kbase/launch_security_sev.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst index 19b978481a..cfdc2a6120 100644 --- a/docs/kbase/launch_security_sev.rst +++ b/docs/kbase/launch_security_sev.rst @@ -30,7 +30,7 @@ Enabling SEV on the host ======================== Before VMs can make use of the SEV feature you need to make sure your -AMD CPU does support SEV. You can run ``libvirt-host-validate`` +AMD CPU does support SEV. You can run ``virt-host-validate`` (libvirt >= 6.5.0) to check if your host supports secure guests or you can follow the manual checks below. -- 2.26.2
On a Wednesday in 2020, Erik Skultety wrote:
I overlooked this typo during review of 2c3ffa37.
Please do not follow commit hashes directly by a period. * rephrase the sentence * just drop the period * include a separator like <> or put in into the Fixes: tag Jano
Reported-by: Yalan Zhang <yalzhang@redhat.com> Signed-off-by: Erik Skultety <eskultet@redhat.com> ---
Pushed as trivial.
docs/kbase/launch_security_sev.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst index 19b978481a..cfdc2a6120 100644 --- a/docs/kbase/launch_security_sev.rst +++ b/docs/kbase/launch_security_sev.rst @@ -30,7 +30,7 @@ Enabling SEV on the host ========================
Before VMs can make use of the SEV feature you need to make sure your -AMD CPU does support SEV. You can run ``libvirt-host-validate`` +AMD CPU does support SEV. You can run ``virt-host-validate`` (libvirt >= 6.5.0) to check if your host supports secure guests or you can follow the manual checks below.
-- 2.26.2
On Wed, Jul 08, 2020 at 01:28:49PM +0200, Ján Tomko wrote:
On a Wednesday in 2020, Erik Skultety wrote:
I overlooked this typo during review of 2c3ffa37.
Please do not follow commit hashes directly by a period. * rephrase the sentence * just drop the period * include a separator like <> or put in into the Fixes: tag
I remember you used to oppose the idea of using the Fixes/Resolves tags in commit messages and be quite adamant about it, so looks strange you would suggest it. Anyhow, noted, I forgot that the period breaks the double click selection of the hash. Erik
On a Wednesday in 2020, Erik Skultety wrote:
On Wed, Jul 08, 2020 at 01:28:49PM +0200, Ján Tomko wrote:
On a Wednesday in 2020, Erik Skultety wrote:
I overlooked this typo during review of 2c3ffa37.
Please do not follow commit hashes directly by a period. * rephrase the sentence * just drop the period * include a separator like <> or put in into the Fixes: tag
I remember you used to oppose the idea of using the Fixes/Resolves tags in commit messages and be quite adamant about it,
I objected to their usage with links to bugzilla, since the word seems redundant in combination with a bugzilla link (especially since it is only intended for human consumption). Or, if you say 'Resolves' on a preparatory patch, you're actually lying in the current commit message. Plain https: links mess with git's interpret-trailers functionality, but that can be worked around in your .gitconfig: [trailer "https"] key = https: ifExists = doNothing With commit message IDs, if you dropped a plain one without a context, I would not know whether you find a bug in it, or just took it as an inspiration.
so looks strange you would suggest it.
I've known you for a few years now, surely there would be other things by now I've had a change of heart about. :) Jano
Anyhow, noted, I forgot that the period breaks the double click selection of the hash.
Erik
participants (2)
-
Erik Skultety -
Ján Tomko