jesseduffield/lazygit · info

Nested rename found

Error message

Nested rename found

What it means

Defensive recursion guard in BeforeAndAfterFileForRename: after expanding a rename into its before/after files using --no-renames, either half still reports IsRename(). The comment notes this 'probably won't happen' — with --no-renames git should never emit rename entries — but the check prevents an infinite recursion if it ever did.

Source

Thrown at pkg/commands/git_commands/working_tree.go:116

	var beforeFile *models.File
	var afterFile *models.File
	for _, f := range filesWithoutRenames {
		if f.Path == file.PreviousPath {
			beforeFile = f
		}

		if f.Path == file.Path {
			afterFile = f
		}
	}

	if beforeFile == nil || afterFile == nil {
		return nil, nil, errors.New("Could not find deleted file or new file for file rename")
	}

	if beforeFile.IsRename() || afterFile.IsRename() {
		// probably won't happen but we want to ensure we don't get an infinite loop
		return nil, nil, errors.New("Nested rename found")
	}

	return beforeFile, afterFile, nil
}

// DiscardAllFileChanges directly
func (self *WorkingTreeCommands) DiscardAllFileChanges(file *models.File) error {
	if file.IsRename() {
		beforeFile, afterFile, err := self.BeforeAndAfterFileForRename(file)
		if err != nil {
			return err
		}

		if err := self.DiscardAllFileChanges(beforeFile); err != nil {
			return err
		}

		if err := self.DiscardAllFileChanges(afterFile); err != nil {

View on GitHub (pinned to c477a2959b)

Solutions

1. Check `git status --no-renames` actually lists delete+add pairs, not 'R' entries, in the affected repo
2. Remove any git wrapper/shim from PATH that drops the --no-renames argument
3. Report upstream if a stock git exhibits it

Practically unreachable defensive guard: if hit, log the no-renames status output and report upstream; there is no caller-side workaround other than verifying `git status --no-renames` behaves correctly and removing git shims from PATH.

When it happens

Trigger: Essentially unreachable with current git: would require the no-renames status listing to still carry rename pairs (custom git wrapper, exotic git version, or pathological index state).

Common situations: A git wrapper script that strips the --no-renames flag; git implementations that ignore the flag.

Related errors

• unexpected git output
• Expected renamed file
• Could not find deleted file or new file for file rename
• Git version must be at least %s. Please upgrade your git ver
• Lazygit does not support bare repos.

AI-assisted analysis of jesseduffield/lazygit@c477a2959b (2026-08-15). Data as JSON: /api/errors/701b43ba16490ed9. Report an issue: GitHub.