[BUG?] Confusion with git stash list

[BUG?] Confusion with git stash list

[rsbecker]

Hi Team,

When using git stash list --all, I end up with every commit showing up in
the list of stash entries. I do not know whether this is intended.

It is simple to set up. You do need at least one stash, but the contents are
irrelevant. So given any repository, use git stash push. Then use git stash
list --all.

When no stashes exist, nothing is output:
$ git stash list --all

When adding a stash (the type of stash does not matter):
$ touch test1
$ git stash push -u
$ git stash list --all
stash@{0}: WIP on PROJ-710-allow-sub-volumes-to-split-arbitrary: 6909776a
t2406: add pattern sync test
HEAD@{0}: reset: moving to HEAD
stash@{0}: WIP on PROJ-710-allow-sub-volumes-to-split-arbitrary: 6909776a
t2406: add pattern sync test
origin/ PROJ-710-allow-sub-volumes-to-split-arbitrary@{0}: push:
forced-update
PROJ-710-allow-sub-volumes-to-split-arbitrary@{0}: commit: t2406: add
pattern sync test
HEAD@{1}: commit: t2406: add pattern sync test
origin/PROJ-710-allow-sub-volumes-to-split-arbitrary@{1}: update by push
PROJ-710-allow-sub-volumes-to-split-arbitrary@{1}: rebase (finish):
refs/heads/PROJ-710-allow-sub-volumes-to-split-arbitrary onto
fea6b45d8671660014d84f5b4538d66c1b91deab
HEAD@{2}: rebase (finish): returning to
refs/heads/PROJ-710-allow-sub-volumes-to-split-arbitrary
HEAD@{3}: rebase (fixup): PROJ-710: Prototype structure for mapping multiple
directories to a subvolume
HEAD@{4}: rebase (fixup): # This is a combination of 17 commits.
HEAD@{5}: rebase (fixup): # This is a combination of 16 commits.
HEAD@{6}: rebase (fixup): # This is a combination of 15 commits.
HEAD@{7}: rebase (fixup): # This is a combination of 14 commits.
HEAD@{8}: rebase (fixup): # This is a combination of 13 commits.
HEAD@{9}: rebase (fixup): # This is a combination of 12 commits.
etc...

This happens in 2.39.0.

Thanks,
Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

Re: [BUG?] Confusion with git stash list

[Chris Torek]

On Fri, Jul 21, 2023 at 9:05 AM <rsbecker@nexbridge.com> wrote:
> It is simple to set up. You do need at least one stash, but the contents are
> irrelevant. So given any repository, use git stash push. Then use git stash
> list --all.

The `git stash list` command is secretly just a front end to `git log`
that inserts particular options, so `--all` is passed to `git log` and
does what it does. That's why you see what you see (remember
that `git stash list` includes `-g` / `--walk-reflogs` so `--all` here
means "all reflogs").

Whether this is *intended* is another question, but to stop it,
`git stash` would have to notice and alter / remove `--all` before
passing the rest of the command on to `git log`.

Chris

Re: [BUG?] Confusion with git stash list

[Junio C Hamano]

Chris Torek <chris.torek@gmail.com> writes:

> On Fri, Jul 21, 2023 at 9:05 AM <rsbecker@nexbridge.com> wrote:
>> It is simple to set up. You do need at least one stash, but the contents are
>> irrelevant. So given any repository, use git stash push. Then use git stash
>> list --all.
>
> The `git stash list` command is secretly just a front end to `git log`
> that inserts particular options, so `--all` is passed to `git log` and
> does what it does. That's why you see what you see (remember
> that `git stash list` includes `-g` / `--walk-reflogs` so `--all` here
> means "all reflogs").
>
> Whether this is *intended* is another question, but to stop it,
> `git stash` would have to notice and alter / remove `--all` before
> passing the rest of the command on to `git log`.

I do not think it was intended, but falls within the realm of "do
not do it, if it hurts" ;-)