[Bug] Stash X Files - stashes all

[SebastianSchumann]

If you have many changed files, you can use the context menu to stash a selection of them. That works as expected if these files are unstaged.

If all files are staged this operation stashes all staged files, but reverts only the selected ones.

Expectation would be to only stash the selected files even if they are staged.

[love-linger]

I checked the git stash documentation and couldn't find a relevant command to do this. If anyone knows, please comment below

[aikawayataro]

I think git stash --staged -- [FILES] can't be used here because:

The new stash entry records the modified states only for the files that match the pathspec. The index entries and working tree files are then rolled back to the state in HEAD only for these files, too, leaving files that do not match the pathspec intact.

This lead to unexpected behavior like this:

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   a
        new file:   b
        new file:   c
        new file:   d
        new file:   e
        new file:   f

$ git stash --staged -- a
Saved working directory and index state WIP on master: 1f6f93c test
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b
        new file:   c
        new file:   d
        new file:   e
        new file:   f

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    b
        deleted:    c
        deleted:    d
        deleted:    e
        deleted:    f

Not only because --staged will store everything you put in staged, but also because pathspec a is the only pathspec stashed explicitly, other files that were stashed by --staged now "fell off" git's track, and accounted as "deleted".

To stash only selected staged files, I believe you can use the double-stash trick:

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   a
        new file:   b
        new file:   c
        new file:   d
        new file:   e
        new file:   f

# stash everything temporary
$ git stash push --staged
Saved working directory and index state WIP on master: 1f6f93c test
# checkout only files that will go to final stash
$ git checkout stash@{0} -- a
$ git status 
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   a

# push final stash
$ git stash push --staged
Saved working directory and index state WIP on master: 1f6f93c test

# restore everything else
$ git checkout stash@{1} -- b c d e f
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b
        new file:   c
        new file:   d
        new file:   e
        new file:   f

# drop temp stash
$ git stash drop stash@{1}
Dropped stash@{1} (a99eae8ccecccbf9df2d10a3f89a5e16cd48fe46)

# verify
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b
        new file:   c
        new file:   d
        new file:   e
        new file:   f

$ git stash show 
 a | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

This trick is quite dirty, but I think it is the only solution.

[love-linger]

@aikawayataro I've test the double-stash solution you provided above. Unfortunately, this operation has a serious problem. If the selected file contains both unstaged and staged changes, its unstaged changes will be discarded after git checkout stash @{0} -- <path>.

[love-linger]

After considering Fork's approach, I decided to make the following modifications:

1. Clicking the Stash button on the toolbar, that is, when the target file(s) is not specified, the option Only staged changes appears
2. When stash with selected file(s), prompt the user "All changes to the file (including unstaged and staged changes) will be stashed"

[aikawayataro]

Unfortunately, this operation has a serious problem. If the selected file contains both unstaged and staged changes, its unstaged changes will be discarded

It is a nice catch! You can still workaround this but hell no, it is too much complexity 😁

I believe your decision is more natural and less error prone. One doubt I have is:

When stash with selected file(s), prompt the user "All changes to the file (including unstaged and staged changes) will be stashed"

How will it work in the situation like this?

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   a
        new file:   b
        new file:   c
        new file:   d
        new file:   e
        new file:   f

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   a

[love-linger]

it will traits all stashed changes as unstaged when you try to apply/pop it

[aikawayataro]

I just tested the latest commit and it still stashes all staged changes in addition to single file I choose to stash

[love-linger]

I just tested the latest commit and it still stashes all staged changes in addition to single file I choose to stash

I can not reproduce this issue. Could you please debug it by adding breakpoint in Commands.Stash.Push(List<Models.Change> changes, string message, bool onlyStaged), and check why the onlyStaged is true

[love-linger]

I tested the git stash push -- <part_of_stage_file> in commandline, and the result is the same. I also tried the same operation in Fork and got the same result.

[love-linger]

It seems that the changes in staged will always be added to stash