Re: Apparent bug in 'git stash push <subdir>' loses untracked files

Hi Thomas,

On 14/12/2017 00:14, Thomas Gummerer wrote:

quoted

For what it`s worth, using `git stash save <subdir>` instead seems
to (still) work as expected...

I think that depends on what you expect ;) 'git stash save <subdir>' 
will create a stash of the whole working directory with the message 
"<subdir>". So while it would indeed work for the presumably 
simplified example Reid provided, it would not do what you'd expect
if there are any tracked and modified files outside of the <subdir>.

In that case 'git stash save <subdir>' would include the tracked
files outside of <subdir>, while what I assume Reid wanted is to keep
them in place, and only stash the files in <subdir>.

Indeed, I didn`t pay enough attention to the fact that even `git 
stash save\push` produced different output messages, the difference 
being exactly automatic (push) versus provided (save) stash message.

And I did use `git stash save <message>` in the past... :$ Not too 
often, I guess.

quoted

but on the other hand, `git-stash`[1] manpage seems not to mention
this usage ("save" with "pathspec")?

"stash save" with "pathspec" doesn't exist, and it will probably
never exist. We decided to introduce a new "push" verb for 'git
stash' because the command line for 'git stash save' takes a message
as its last argument, instead of taking the message with a -m flag
like other commands do. Introducing a pathspec argument for "git
stash save" would have either broken backward compatibility, or it
would have had some syntax that's very inconsistent with other git
commands.

Yeah, I`m aware of the "transition", thus teaching myself to use `git 
stash push` lately. That`s also what made me curious to try out the 
"old" `git stash save` behavior, but obviously in a bit hasty manner.

Sorry for the confusion, and thanks, for both clarification 
and your work.

Regards, Buga