[Critical Bug] findGitRoot() causes catastrophic data loss when parent directory contains .git

[a88883284]

What Happened

I lost 3,711 files in my home directory because evolver executed git reset --hard in the wrong directory.

My Setup

• Evolver installed at: ~/.openclaw/workspace/skills/evolver/ (as a skill in OpenClaw workspace)
• Parent directory ~/.openclaw/ had a .git folder (created unintentionally at some point)
• Evolver running in loop mode via cron

The Bug

In src/gep/paths.js, the findGitRoot() function walks up the directory tree and returns the first .git it finds:

function findGitRoot(startDir) {
  let dir = startDir;
  while (dir && dir !== path.dirname(dir)) {
    const gitDir = path.join(dir, '.git');
    if (fs.existsSync(gitDir)) {
      return dir;  // Returns parent's .git, not evolver's own!
    }
    dir = path.dirname(dir);
  }
}

When evolution failed and triggered rollback, git reset --hard was executed in ~/.openclaw/ instead of ~/.openclaw/workspace/skills/evolver/.

Result: Everything in my home directory that wasn't committed to git was destroyed - including credentials, configurations, agent sessions, memory databases, and custom skills.

Root Cause

The function assumes that if a parent directory has .git, it's an intentional nested installation. But users often have .git folders in parent directories for various reasons:

• Accidental git init
• The parent is itself a project
• Previous installations left behind

There's no safeguard to ensure evolver only operates within its own directory.

Proposed Fix

Modify findGitRoot() to only use evolver's own .git, and require explicit opt-in for parent git repos:

function findGitRoot(startDir) {
  let dir = startDir;
  let foundGitRoot = null;
  
  while (dir && dir !== path.dirname(dir)) {
    const gitDir = path.join(dir, '.git');
    if (fs.existsSync(gitDir)) {
      foundGitRoot = dir;
      break;
    }
    dir = path.dirname(dir);
  }
  
  // Safety: Only use parent's git if explicitly allowed
  if (foundGitRoot && foundGitRoot !== startDir) {
    if (process.env.EVOLVER_USE_PARENT_GIT === 'true') {
      console.warn('[Evolver] Using parent git repository at:', foundGitRoot);
      return foundGitRoot;
    }
    // Default: Use evolver's own directory, even if no .git exists
    console.warn('[Evolver] Parent directory has .git but EVOLVER_USE_PARENT_GIT is not set. Using evolver directory.');
    return startDir;
  }
  
  return foundGitRoot || startDir;
}

This ensures:

1. Evolver defaults to its own directory (safe)
2. Parent git repos require explicit opt-in via environment variable
3. Users are warned when a parent .git is detected but ignored

Impact

This is a data loss bug that can affect anyone who:

• Installs evolver as a subdirectory in an existing project
• Has a .git folder anywhere in the parent directory chain

The current behavior is dangerous and should be fixed before more users lose their data.

[a88883284]

Update: Deeper Analysis

After further investigation, I realize the root cause is more nuanced.

The Real Problem

The disaster happened because of git reset --hard origin/main, not just git reset --hard.

In my case:

1. My home directory ~/.openclaw/ had a .git folder (created accidentally)
2. The git remote pointed to some npm package repository
3. git reset --hard origin/main replaced my entire directory with that package's content
4. All 3,711 local files were destroyed

Why findGitRoot() Upward Search Can Be Legitimate

Evolver uses sessions_spawn() to call external agents that may modify files anywhere in the workspace:

• workspace/memory/
• agents/
• skills/

If git only tracks the evolver directory itself, rollback won't restore changes made elsewhere. The upward search was intentional for this use case.

Better Fix

Instead of blocking parent git repos, we should add safety checks before destructive git operations:

function safeResetHard(repoRoot, target = 'HEAD') {
  // Check for untracked files that would be lost
  const untracked = execSync('git ls-files --others --exclude-standard', { 
    cwd: repoRoot, encoding: 'utf8' 
  }).trim();
  
  if (untracked) {
    const count = untracked.split('\n').filter(Boolean).length;
    console.error(\);
    console.error('[Evolver] Consider using EVOLVER_ROLLBACK_MODE=stash instead');
    // Optionally: abort or require confirmation
    throw new Error(\);
  }
  
  execSync(\, { cwd: repoRoot });
}

This way:

1. Normal users with clean repos are unaffected
2. Users with accidental git setups are protected
3. Evolver's rollback functionality remains intact for its intended use case

I'll submit a PR with this approach.

[autogame-17]

Thanks for the detailed report @a88883284. This is a well-documented issue and we appreciate the thorough analysis.

You're right that the upward .git search in findGitRoot() can be dangerous when an unintended .git exists in a parent directory. Your follow-up comment correctly identifies the nuance -- the upward search is intentional for workspace-level rollback, but the destructive git reset --hard needs safeguards.

We've reviewed both the issue and your related PR #196 (EVOLVER_ROLLBACK_MODE). The PR approach of adding stash and none modes is a pragmatic mitigation. We're merging it into the upstream codebase.

For a more comprehensive fix, we're also considering:

1. Adding an untracked-file count check before git reset --hard (as you suggested in your follow-up)
2. Logging a warning when findGitRoot() returns a directory that is not the evolver install directory

These will be tracked internally. Thanks again for the report and the PR -- your contribution will be included in the next release.