From db103fa046c2d3fa4a820b77283149df998d8d66 Mon Sep 17 00:00:00 2001
From: Illy <89575292+IllyStable@users.noreply.github.com>
Date: Thu, 28 Nov 2024 07:02:44 +0000
Subject: [PATCH] Update component.rs require docs

---
 crates/bevy_ecs/src/component.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crates/bevy_ecs/src/component.rs b/crates/bevy_ecs/src/component.rs
index b915f8b5cad09..10466f8391225 100644
--- a/crates/bevy_ecs/src/component.rs
+++ b/crates/bevy_ecs/src/component.rs
@@ -228,7 +228,7 @@ use derive_more::derive::{Display, Error};
 ///
 /// In general, this shouldn't happen often, but when it does the algorithm is simple and predictable:
 /// 1. Use all of the constructors (including default constructors) directly defined in the spawned component's require list
-/// 2. In the order the requires are defined in `#[require()]`, recursively visit the require list of each of the components in the list (this is a Depth First Search). When a constructor is found, it will only be used if one has not already been found.
+/// 2. In the order the requires are defined in `#[require()]`, recursively visit the require list of each of the components in the list (this is a Breadth First Search). When a constructor is found, it will only be used if one has not already been found.
 ///
 /// From a user perspective, just think about this as the following:
 /// 1. Specifying a required component constructor for Foo directly on a spawned component Bar will result in that constructor being used (and overriding existing constructors lower in the inheritance tree). This is the classic "inheritance override" behavior people expect.