jesseduffield
feat: Persistent Command Log
Thanks for an amazing project! I actually wrote a blog post about lazygit recently (feedback welcome), just to share awareness in my circles: https://www.bwplotka.dev/2025/lazygit/
Is your feature request related to a problem? Please describe.
Command log only shows actions lazygit did in the current session. It's very common to close lazy git and bring back after days on a certain repo, or accidently close lazygit and lose the history.
This is a problem when then trying to remember what was the branch on you touched in the recent past, what tag you were adding some time ago (was it you or some other person from outside), did you rebase to correct branch etc.
It would be epic if command log was persistent for a single user on a single machine.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Command log sharing a single file on filesystem (can be opt-in), like bash history.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
- Not doing it.
- Having a server side shared history (too much work, not that needed, also one could do that on their own similar to bash history logs).
Additional context
Add any other context or screenshots about the feature request here.
This is a problem when then trying to remember what was the branch on you touched in the recent past, what tag you were adding some time ago (was it you or some other person from outside), did you rebase to correct branch etc.
That would require either having separate log files (per repo), or filtering of the log just for the current repo, but then it would maybe be better to use a database like sqlite (since it just uses an ordinary file we could store alongside state.yml).
@stefanhaller I'm keen on hearing your thoughts on this.
We could consider saving the log in .git/LAZYGIT_COMMAND_LOG (we already use this approach with .git/LAZYGIT_PENDING_COMMIT for the preserved commit message when you cancel out of the c dialog).
Some other questions though:
- what if you start two lazygit instances in the same repo? Happens for me occasionally; we'd have to make sure that they don't overwrite each other's log.
- what do we do about the "tip of the day"? I'm not super convinced that these are really useful, but right now we print one at the beginning of the log on each start. These would have to go somewhere else then, but I don't know where. (Or maybe it's ok to keep logging them at startup, and they will just end up in the middle of the persistent log then?)
- we'd probably need to truncate the log in case it gets too long over time. Is it ok to do that line-based? We might truncate in the middle of a multi-line entry.
- do we need timestamps so that you can tell how long ago the entries are?
what if you start two lazygit instances in the same repo? Happens for me occasionally; we'd have to make sure that they don't overwrite each other's log.
Yes, with the log idea, we need try to >> text to files or some other concurrent writes technique, to preserve both. Truncating/rotating is another thing to be careful with
what do we do about the "tip of the day"? I'm not super convinced that these are really useful, but right now we print one at the beginning of the log on each start. These would have to go somewhere else then, but I don't know where. (Or maybe it's ok to keep logging them at startup, and they will just end up in the middle of the persistent log then?)
It feels having those in the log is fine as a first iteration.
we'd probably need to truncate the log in case it gets too long over time. Is it ok to do that line-based? We might truncate in the middle of a multi-line entry.
For one writer, it's not a problem, it's only problem if one lazygit truncates/rotate and second is in the middle of write, right? I think we could slowly iterate for multiple writers, it's not the first priority 🤔
do we need timestamps so that you can tell how long ago the entries are?
That would be amazing! At this point, we could use simple slog.Log implementation 🙈