Make 'git stash list' more informative

Make 'git stash list' more informative

[Yuri]

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

Re: Make 'git stash list' more informative

[Lucas Seiki Oshiro]

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

`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.

> I propose to amend WIP stash entry descriptions with size, number of dirs and files

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.

> Thanks,
> Yuri

I hope it helps you!

Re: Make 'git stash list' more informative

[Junio C Hamano]

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

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

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 ...

> `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.

... this is an excellent suggestion.

Thanks.

Re: Make 'git stash list' more informative

[Lucas Seiki Oshiro]

> 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.

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.

> ... this is an excellent suggestion.

Thanks :-)