Easy way to checkout/reset/resotre deleted file/folders

[DeeliN221]

Is your feature request related to a problem? Please describe.

When a file was deleted in a past commit, lazygit shows it as D in that commit’s file list. However, pressing c (checkout/restore file) on that D entry fails because lazygit runs git checkout <this_commit> -- , and the path no longer exists in that commit. To restore such a file today, I have to manually locate the parent/previous commit where the file still existed and then press c there. This is inconvenient, especially when the deletion happened long ago or involved multiple files.

Describe the solution you'd like

Possible UX options:

• Pressing c on a D file automatically restores it from ^ (or the nearest ancestor containing the file).
• Or add a separate action like "Restore deleted file from parent commit" in the context menu / keybinding.

Describe alternatives you've considered

Using CLI commands such as:

git checkout <commit>^ -- <file>
git restore --source <commit>^ <file>

Additional context

This feature would be particularly useful for:

• Restoring multiple deleted files quickly.
• Deletions that happened many commits ago (hard to locate the last existing commit).
• Users who rely on lazygit to avoid dropping into the CLI.

If helpful, the underlying logic could be:

• Detect that the file is deleted in the selected commit.
• Run git checkout <commit>^ -- <file>

[stefanhaller]

Try pressing space on the file to stage the deletion into a custom patch; then, bring up the custom patch menu (ctrl-p) and choose "Apply patch in reverse". There's your file again.

This is three keystrokes: space, ctrl-p, r. I don't feel like we need to add anything else to lazygit to make this easier for this special case.

[DeeliN221]

Thanks for sharing that solution — I didn’t know about it. That said, a three-keystroke flow feels noticeably less convenient than a single keystroke (just pressing c on the deleted file).

If adding this shortcut wouldn’t break any existing behavior and isn’t too hard to implement, I’d prefer to keep the original idea. As far as I know, pressing c on an already-committed deleted file currently does nothing useful — it only errors out — so enabling it there shouldn’t conflict with current logic.

I’m happy to submit a PR if this sounds acceptable.

[stefanhaller]

No, pressing c to get back a deleted file is just wrong, conceptually. c is for checking out a file in the state that it has in a given commit; in this case the file doesn't exist in that commit, so trying to check it out results in an error. This is totally the expected behavior for me. Typing git checkout <commit-hash> -- <filepath> on the command line would result in the exact same error, and it makes sense.

If anything, we could improve the situation by displaying a better error message, maybe one that contains a hint of what to do instead if you want to revert deleting the file. Actually, I think we should disable (strike out) the command when a deleted file is selected, like we do for many other commands when they are not applicable in a given situation.

[DeeliN221]

I agree. Since, conceptually, one can’t run checkout on a file that has already been deleted, we might as well replace it with restore (bound to the r key by default). It sounds more intuitive and convenient for me.