`e` in commits view should `git show`

[Axlefublr]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

In the commits view, after you press enter on a commit, you can then press e to edit each individual file.
Unfortunately, you go and edit the actual file, while it would be a lot more useful to edit the file at that commit. \

Describe the solution you'd like
A clear and concise description of what you want to happen.

git show hash:path can be used for this! :)

The reasoning for the idea, is that you can already press e to edit files as they actually are, when in the status view; there doesn't seem to be a convenient way to open a file at some certain commit (you don't always want to checkout)

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[stefanhaller]

The current behavior of e in the commits view is very much the expected and desired one. The use case is that you are looking through the commits in your branch, find something to fix, and want to quickly jump to your editor to make the change. (Although I admit that with the support for delta's hyperlinks this has become a much less frequent interaction for me, as you can now jump to the editor right from the commits view without having to press enter to view the files. But still.)

If anything, what bothers me about it is that often the line numbers are off if there are further changes to the file later in the branch. It would (theoretically) be possible to fix this by working out how the line numbers change in the later commits, but that's a lot of work and probably slow. (And doesn't always work, if the hunk that you are looking at has been deleted by a later commit.)

What you suggest would be a different command; it's a bit unclear to me how it would be implemented, because the file would have to be saved to a temp file, but when would it be cleaned up? Never?

Anyway, you can approximate the behavior with a custom command similar to this one (if you are using VS Code):

customCommands:
    - key: "e"
      command: 'git show "{{.SelectedCommit.Hash}}:{{.SelectedPath}}" | code -'
      context: "commitFiles"

[Axlefublr]

looking through the commits in your branch, find something to fix, and want to quickly jump to your editor to make the change

Interesting! works oppositely in my brain, it makes more sense for me to go back to my editor and search for the file, because subconsciously I assume the file view in commits shows "old files" and I would be wanting to change the file at its current state. I would love to hear if anyone else has opinions on this.

when would it be cleaned up

After the editor exits? I assumed that while you have the editor open from lazygit, it holds the thread (because it's being used by the editor), rather than being async. But I guess that wouldn't be the case with vscode, but I'm also even more surprised that there are people who use both vscode and lazygit.

you can approximate the behavior...

Thank you! I appreciate you making the command for me! However I more so started this issue to discuss whether the default behavior makes sense, rather than get the feature for just myself. So would be lovely to keep this issue open for some more time to see what other people's opinions on this are. Maybe I'm the minority?

[parthokunda]

I more so started this issue to discuss whether the default behavior makes sense, rather than get the feature for just myself. So would be lovely to keep this issue open for some more time to see what other people's opinions on this are.

I think "e" keypress in the commit pane is good as it is. I do not find myself editing previous commits so often (most often I only edit the previous commit using git amend).

If anything, what bothers me about it is that often the line numbers are off if there are further changes to the file later in the branch. It would (theoretically) be possible to fix this by working out how the line numbers change in the later commits, but that's a lot of work and probably slow. (And doesn't always work, if the hunk that you are looking at has been deleted by a later commit.)

This is an issue that might affect some people tbh. Worth exploring for a fix.

[Axlefublr]

it's a bit unclear to me how it would be implemented, because the file would have to be saved to a temp file, but when would it be cleaned up? Never?

@stefanhaller today I learned that inotifywait can be used to solve this exact question, although it does assume linux. Might be helpful, still, for people in the future wondering the same question you had.

[stefanhaller]

If anything, what bothers me about it is that often the line numbers are off if there are further changes to the file later in the branch. It would (theoretically) be possible to fix this by working out how the line numbers change in the later commits, but that's a lot of work and probably slow.

It turns out that it's not that hard to fix this. Here's a PR: #4119.

[parisni]

I think "e" keypress in the commit pane is good as it is. I do not find myself editing previous commits so often

Maybe i am misunderstanding but edit is not about editing the history, but about opening the file in the editor and that's it. Let's say to select some interesting subset, and closing.

looking through the commits in your branch, find something to fix, and want to quickly jump to your editor to make the change

Interesting! works oppositely in my brain, it makes more sense for me to go back to my editor and search for the file, because subconsciously I assume the file view in commits shows "old files" and I would be wanting to change the file at its current state. I would love to hear if anyone else has opinions on this.

Agreed on the latter. I usually dig the git history to remind how was the code at that time. Once found both revision and file, opening that revision/file with editor sounds more legit than going back to the current version.

it's a bit unclear to me how it would be implemented, because the file would have to be saved to a temp file, but when would it be cleaned up? Never?

Yeah, just never. That's what we expect from /tmp/ folder anyway: purged by OS

[Axlefublr]

@parisni you are very much correct! opening some file at an older commit, to copy some section in it is a very common usecase I have