Log output of stash drop command(s)

[nielsbauman]

It can be useful to see the reference hash of a stash after dropping it. This makes recovering the dropped stash a lot easier if the stash was dropped accidentally.

[stefanhaller]

I see how this can be useful. The implementation is not quite what we need though, because the functions that you added the logging to are sometimes used internally (e.g. when renaming a stash), and we don't want the logging noise in that case.

Also, shouldn't we log the hash when popping as well? Maybe that doesn't happen as often, but you could imagine you accidentally pop a stash instead of applying it, and then discard the changes; would be nice to be able to restore it in that case, too. For this case though, logging git's output is not what we want, because unlike with drop it prints a whole bunch of stuff which we probably don't want to see. So I wonder if we should rather print the hash to the log ourselves (in both cases) instead of logging git's output.

And finally, it might be worth thinking about even better ways to solve the problem. Your solution is certainly better than nothing, but it has two problems:

• you need to be an expert to know how to restore a stash from a hash (I only learned today that you can do git stash apply <hash> for that)
• you need to do it while lazygit is still running. Once you quit, the information is lost.

It might be nice to have a feature where lazygit records information about dropped or popped stashes more permanently, and then has a user interface for browsing these and restoring them. I suppose this could be an extra tab in the stashes panel. The biggest challenge is probably how to garbage-collect these. Of course, such a feature is way more work than just logging the hash, so I'm happy to go with the simpler solution in the meantime.

[stefanhaller]

So I wonder if we should rather print the hash to the log ourselves (in both cases) instead of logging git's output.

I made a PR that does this if you want to have a look: #4850. It fixes a few other minor problems.

While working on this I noticed a pretty bad bug with dropping a range selection, which I fixed in a different PR (#4849, already merged).

[nielsbauman]

Hi @stefanhaller, thanks so much for your quick reply!

Also, shouldn't we log the hash when popping as well?

I decided not to, because (AFAIK) no state is lost when popping a stash - either it succeeds and you can stash the changes again or it fails and git retains the stash entry. But there's no harm in logging it anyway :)

Your solution is certainly better than nothing, but it has two problems:

I completely agree with both points. I think a feature like you suggested sounds much better, I just didn't/don't have the time to implement something like that (I'm also not familiar with Go at all), so I indeed figured this would be better than nothing.

I made a PR that does this if you want to have a look

That looks great! Thanks very much for the quick replies and action!

[stefanhaller]

no state is lost when popping a stash

While that's true, I can still imagine workflows where you could lose a stash after popping. Suppose you are bisecting, and for every bisection step you need a certain patch. It would make sense to stash this patch, and then apply it at every step and then discard the changes again. If at some point you accidentally pop instead of apply, and only notice after you discarded the changes again, the stash is lost.

That looks great!

Cool, gonna merge it then and we can close this.