Make 'git stash list' more informative

Currently 'git stash list' prints lines like this: stash@{10}: WIP on main: 3f802b772d88 science/py-pymatgen: update 2025.1.24 → 2025.2.18

It contains the last commit's subject which often/usually doesn't really describe the stash entry.

I propose to amend WIP stash entry descriptions with size, number of dirs and files, and time description, so that the above entry might look like this:

stash@{10}: WIP on main: 3f802b772d88 science/py-pymatgen: update 2025.1.24 → 2025.2.18 (+20, -5, 3 dirs, 5 files, 17 days ago)

It would add info about the number of changed lines, number of affected directories and files, and how old this stash record is.

This would make WIP stash lines much more informative and they would actually describe better what is in them.

Thanks, Yuri

`git stash list` accepts the options from `git log`, so you can change look at its manpage to find other options that show the information that you want.

Perhaps this helps you:

`git stash list --stat --pretty=reference`

You can customize following the format described on https://git-scm.com/docs/pretty-formats.

I hope it helps you!

Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:

It depends on how you work.

I do agree that the work recorded in the stash entries tend to be pretty much unrelated to the work I was doing on the branch (hence the theme of the base commit). After all, if they are related, you're more likely not keeping the work in the stash entries---you'd rather be making completed commit on the branch.

However, I find that the subject of the base commit the stashed work was derived from works well as a memory aid to recall what I was working on when the stash entry was created.

So "doesn't really describe" is correct, but because stash is by design a local thing, it is not a failure that it "doesn't really describe"---the purpose of the message is to be something easily generated and help jog your memory later.

Having said that ...

... this is an excellent suggestion.

Thanks.

I don't if this the use case of Yuri, but in the past I kept a stash entry with some local development changes that shouldn't be committed and sent to the main repository. This is, I always applied that stash entry, did what I needed in my local environment, removed the code that was applied, then I committed the changes that should went to production.

It soon became hard to manage as I needed to use stash for other things. But hey, stash entries are commits, so I could somehow mimic its behavior without using stash itself! So, what I did:

1. Detached the HEAD:

$ git checkout --detach

2. Committed the local development changes. You can use the commit
message body to write a description of what those changes are.

$ git add my_changed_file $ git commit

3. Created a local tag, just for me:

$ git tag LOCAL_SETUP

4. Whenever I wanted to use that code, I just applied it by using:

$ git merge --squash LOCAL_SETUP $ git reset

This left the Git stash stack free for other uses and I could use it without worrying about the stash positions. If the problem is to have control over the stash, maybe the solution is to use the good old commits.

Thanks :-)