git/git-stash.sh, branch v2.16.2

Merge branch 'tg/stash-with-pathspec-fix' into maint

2018-02-15T23:18:13Z

"git stash -- " incorrectly blew away untracked files in the directory that matched the pathspec, which has been corrected. * tg/stash-with-pathspec-fix: stash: don't delete untracked files that match pathspec

stash: don't delete untracked files that match pathspec

2018-01-08T21:02:25Z

Currently when 'git stash push -- ' is used, untracked files that match the pathspec will be deleted, even though they do not end up in a stash anywhere. This is because the original commit introducing the pathspec feature in git stash push (df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor pathspec", 2017-02-28)) used the sequence of 'git reset && git ls-files --modified | git checkout-index && git clean '. The intention was to emulate what 'git reset --hard -- ' would do. The call to 'git clean' was supposed to clean up the files that were unstaged by 'git reset'. This would work fine if the pathspec doesn't match any files that were untracked before 'git stash push -- '. However if matches a file that was untracked before invoking the 'stash' command, all untracked files matching the pathspec would inadvertently be deleted as well, even though they wouldn't end up in the stash, and are therefore lost. This behaviour was never what was intended, only blobs that also end up in the stash should be reset to their state in HEAD, previously untracked files should be left alone. To achieve this, first match what's in the index and what's in the working tree by adding all changes to the index, ask diff-index what changed between HEAD and the current index, and then apply that patch in reverse to get rid of the changes, which includes removal of added files and resurrection of removed files. Reported-by: Reid Price Helped-by: Junio C Hamano Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

Merge branch 'ph/stash-save-m-option-fix'

2017-12-06T17:23:43Z

In addition to "git stash -m message", the command learned to accept "git stash -mmessage" form. * ph/stash-save-m-option-fix: stash: learn to parse -m/--message like commit does

stash: learn to parse -m/--message like commit does

2017-11-24T05:47:44Z

`git stash push -m foo` uses "foo" as the message for the stash. But `git stash push -m"foo"` does not parse successfully. Similarly `git stash push --message="My stash message"` also fails. The stash documentation doesn't suggest this syntax should work, but gitcli does and my fingers have learned this pattern long ago for `commit`. Teach `git stash` to parse -mFoo and --message=Foo the same as `git commit` would do. Even though it's an internal function, add similar support to create_stash() for consistency. Signed-off-by: Phil Hord Signed-off-by: Junio C Hamano

stash: remove now superfluos help for "stash push"

2017-10-27T00:59:11Z

With the 'git stash save' interface, it was easily possible for users to try to add a message which would start with "-", which 'git stash save' would interpret as a command line argument, and fail. For this case we added some extra help on how to create a stash with a message starting with "-". For 'stash push', messages are passed with the -m flag, avoiding this potential pitfall. Now only pathspecs starting with "-" would have to be distinguished from command line parameters by using "-- --". This is fairly common in the git command line interface, and we don't try to guess what the users wanted in the other cases. Because this way of passing pathspecs is quite common in other git commands, and we don't provide any extra help there, do the same in the error message for 'git stash push'. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

stash: replace "git stash save" with "git stash push" in the documentation

2017-10-27T00:58:38Z

"git stash push" is the newer interface for creating a stash. While we are still keeping "git stash save" around for the time being, it's better to point new users of "git stash" to the more modern (and more feature rich) interface, instead of teaching them the older version that we might want to phase out in the future. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

Merge branch 'mf/no-dashed-subcommands' into maint

2017-09-10T08:02:56Z

Code clean-up. * mf/no-dashed-subcommands: scripts: use "git foo" not "git-foo"

Merge branch 'kd/stash-with-bash-4.4'

2017-08-23T21:13:08Z

bash 4.4 or newer gave a warning on NUL byte in command substitution done in "git stash"; this has been squelched. * kd/stash-with-bash-4.4: stash: prevent warning about null bytes in input

Merge branch 'nm/stash-untracked'

2017-08-23T21:13:07Z

"git stash -u" used the contents of the committed version of the ".gitignore" file to decide which paths are ignored, even when the file has local changes. The command has been taught to instead use the locally modified contents. * nm/stash-untracked: stash: clean untracked files before reset

stash: prevent warning about null bytes in input

2017-08-14T22:35:48Z

The `no_changes` function calls the `untracked_files` function through command substitution. `untracked_files` will return null bytes because it runs ls-files with the '-z' option. Bash since version 4.4 warns about these null bytes. As they are not required for the test that is being done, make sure `untracked_files` does not output null bytes when not required. This is achieved by adding a parameter to the `untracked_files` function to specify wither `-z` should be passed to ls-files or not. This warning is triggered when running git stash save -u resulting in two warnings: git-stash: line 43: warning: command substitution: ignored null byte in input Signed-off-by: Kevin Daudt Signed-off-by: Junio C Hamano