src/commands/checkout.js (1)

758-762: Minor: outer catch now double-logs the aggregated error.

Each rejection is already logged with its stack inside the loop (lines 732-735), and the synthetic aggregated error thrown at line 752 will then be caught here and re-logged as FATAL. That's not harmful, but the FATAL log adds little signal beyond the per-task logs above it. Consider only logging FATAL when the caught error is not the synthetic aggregate (i.e., an unexpected error escaped the inner try) — otherwise the per-rejection logs above are sufficient.

This is a stylistic suggestion; current behavior is acceptable and matches the PR's stated intent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/checkout.js` around lines 758 - 762, The outer catch (the catch
(error) that logs `[isomorphic-git ${operationName}] FATAL:`) double-logs the
synthetic aggregated error that was already logged per-rejection inside the
loop; change the outer handler to only log when the caught error is not the
synthetic aggregate (e.g., if !(error instanceof AggregateError) or the error
lacks an .errors array), then rethrow in all cases. Locate the outer catch block
and guard the console.error call accordingly so per-task rejection logs remain
the only logs for aggregated failures while still logging unexpected
non-aggregate exceptions.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/commands/checkout.js (1)

760-764: Outer try/catch produces duplicate logging without adding value.

Every rejection is already console.error'd individually inside the loop (lines 732‑737), and the aggregated Error thrown on line 754 already contains the operation name and a summary. The outer catch then logs the same aggregated error again as FATAL before rethrowing it unchanged — net effect is one extra log line per failed batch with no extra information.

If the only intent is to ensure unexpected throws (e.g., from onProgress) are visible, that's already achieved by callers' own error handling. Consider dropping the outer try/catch entirely, or restricting it to truly unexpected failures (i.e., don't relog the deliberately-thrown aggregate):

♻️ Simplification

 async function batchAllSettled(operationName, tasks, onProgress, batchSize) {
   const results = []
   const rejections = []
-  try {
-    for (let i = 0; i < tasks.length; i += batchSize) {
-      …
-    }
-
-    if (rejections.length > 0) {
-      …
-      throw new Error(…)
-    }
-
-    return results
-  } catch (error) {
-    // eslint-disable-next-line no-console
-    console.error(`[isomorphic-git ${operationName}] FATAL:`, error)
-    throw error
-  }
+  for (let i = 0; i < tasks.length; i += batchSize) {
+    …
+  }
+  if (rejections.length > 0) {
+    …
+    throw new Error(…)
+  }
+  return results
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/checkout.js` around lines 760 - 764, The outer try/catch that
catches errors and does console.error(`[isomorphic-git ${operationName}]
FATAL:`, error) should be removed (or at minimum the catch should not re-log
already-aggregated failures) because each rejection is logged inside the loop
and an aggregated Error is explicitly thrown later; locate the try/catch
surrounding the loop that references operationName and remove the catch block
(or change it to simply rethrow without logging), leaving the loop-level logging
and the aggregated Error throw intact so unexpected errors still propagate from
functions like onProgress but are not double-logged.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/commands/checkout.js (2)

758-758: Optional: enrich the aggregated error message with operation context.

new MultipleGitError(rejections) produces a fixed generic message (There are multiple errors that were thrown by the method...), so unhandled-rejection logs and stack traces lose the operationName and the n/total failed summary that the original PR description called out. Programmatic consumers still get full detail via .errors / .data, so this is purely a diagnostics nicety — feel free to skip if you prefer to keep MultipleGitError instances uniform.

💡 Optional message augmentation

   if (rejections.length > 0) {
-    throw new MultipleGitError(rejections)
+    const err = new MultipleGitError(rejections)
+    err.message = `[isomorphic-git ${operationName}] ${rejections.length}/${tasks.length} tasks failed: ${err.message}`
+    throw err
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/checkout.js` at line 758, The throw currently does "throw new
MultipleGitError(rejections)" which yields a generic message; instead build a
concise diagnostic string that includes the operationName and a "failed n/total"
summary (e.g., `${operationName}: ${rejections.length}/${total} failed`) and
attach it to the thrown error: either pass it into MultipleGitError if its
constructor accepts a message, or create the MultipleGitError instance and set
its message property (and/or a .summary field) before throwing; use the existing
symbols MultipleGitError and rejections (and operationName / total in the
surrounding scope) so logs and unhandled-rejection traces show the enriched
context.

---

350-363: Extract the duplicated rejection-handling logic, and unify the log prefix.

The rejection-collection / per-task logging / aggregated throw is now duplicated between the blocking branch (lines 350‑363) and batchAllSettled (lines 736‑747, 757‑759). Extracting a small helper keeps the two paths in lockstep when this evolves (e.g., adding fail-fast, telemetry, or message customization).

Minor consistency nit: the blocking branch logs [isomorphic-git checkout] task rejected: (hard-coded) while batchAllSettled logs [isomorphic-git ${operationName}] (e.g., "Update Working Dir"). Passing an operationName through to the helper makes log filtering uniform across both paths.

♻️ Sketch: shared helper

+function collectRejections(operationName, settled) {
+  const results = []
+  const rejections = []
+  for (const result of settled) {
+    if (result.status === 'fulfilled') {
+      results.push(result.value)
+    } else {
+      rejections.push(result.reason)
+      // eslint-disable-next-line no-console
+      console.error(
+        `[isomorphic-git ${operationName}] task rejected:`,
+        result.reason?.stack ?? result.reason
+      )
+    }
+  }
+  return { results, rejections }
+}

Then both call sites become:

-          const rejections = []
-          for (const result of settled) {
-            if (result.status === 'rejected') {
-              rejections.push(result.reason)
-              // eslint-disable-next-line no-console
-              console.error(
-                '[isomorphic-git checkout] task rejected:',
-                result.reason?.stack ?? result.reason
-              )
-            }
-          }
-          if (rejections.length > 0) {
-            throw new MultipleGitError(rejections)
-          }
+          const { rejections } = collectRejections('checkout', settled)
+          if (rejections.length > 0) throw new MultipleGitError(rejections)

Also applies to: 730-761

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/checkout.js` around lines 350 - 363, Extract the duplicated
rejection collection, per-task logging and aggregated throwing into a small
helper (e.g., handleSettledRejections(settled, operationName)) and replace the
duplicated blocks in the blocking branch inside checkout.js (the loop that
builds rejections and calls console.error then throws MultipleGitError) and the
batchAllSettled code paths with calls to that helper; the helper should iterate
settled results, push rejected reasons into an array, log each rejection using a
unified prefix that uses operationName (format like `[isomorphic-git
${operationName}] task rejected:`) and, if any rejections exist, throw new
MultipleGitError(rejections). Ensure both callers pass a descriptive
operationName (e.g., "checkout" or the existing operationName used by
batchAllSettled) so log filtering is consistent.