From 153295a5712e9e462d32611c51396665a5029d8b Mon Sep 17 00:00:00 2001
From: Louis Jacomet <louis@gradle.com>
Date: Wed, 1 Dec 2021 12:01:05 +0100
Subject: [PATCH] Minor doc fix

Change done to resolve an internal CI promotion issue
---
 .../viewing_debugging_dependencies.adoc                        | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/subprojects/docs/src/docs/userguide/dep-man/01-core-dependency-management/viewing_debugging_dependencies.adoc b/subprojects/docs/src/docs/userguide/dep-man/01-core-dependency-management/viewing_debugging_dependencies.adoc
index 6a3e9aa22bfd..aca2c387c749 100644
--- a/subprojects/docs/src/docs/userguide/dep-man/01-core-dependency-management/viewing_debugging_dependencies.adoc
+++ b/subprojects/docs/src/docs/userguide/dep-man/01-core-dependency-management/viewing_debugging_dependencies.adoc
@@ -201,7 +201,8 @@ Have a look at the <<variant_model.adoc#sec:variant-select-errors,dedicated sect
 == Resolving unsafe configuration resolution errors
 
 Resolving a configuration can have side effects on Gradle's project model, so Gradle needs manage access to each project's configurations.
-There are a number of ways a configuration might be resolved unsafely. Gradle will produce a deprecation warning for each unsafe access.
+There are a number of ways a configuration might be resolved unsafely.
+Gradle will produce a deprecation warning for each unsafe access.
 Each of these are bad practices and can cause strange and indeterminate errors.
 
 If your build has an unsafe access deprecation warning, it needs to be fixed.