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

Merge branch 'tg/stash-untracked-with-pathspec-fix'

2018-04-09T23:25:45Z

"git stash push -u -- " gave an unnecessary and confusing error message when there was no tracked files that match the , which has been fixed. * tg/stash-untracked-with-pathspec-fix: stash: drop superfluos pathspec parameter stash push -u: don't create empty stash stash push: avoid printing errors stash: fix nonsense pipeline

stash: drop superfluos pathspec parameter

2018-03-21T22:07:46Z

Since 833622a945 ("stash push: avoid printing errors", 2018-03-19) we don't use the 'git clean' call for the pathspec case anymore. The commit however forgot to remove the pathspec argument to the call. Remove the superfluos argument to make the code a little more obvious. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

stash push -u: don't create empty stash

2018-03-20T16:08:34Z

When introducing the stash push feature, and thus allowing users to pass in a pathspec to limit the files that would get stashed in df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor pathspec", 2017-02-28), this developer missed one place where the pathspec should be passed in. Namely in the call to the 'untracked_files()' function in the 'no_changes()' function. This resulted in 'git stash push -u -- ' creating an empty stash when there are untracked files in the repository other that don't match the pathspec. As 'git stash' never creates empty stashes, this behaviour is wrong and confusing for users. Instead it should just show a message "No local changes to save", and not create a stash. Luckily the 'untracked_files()' function already correctly respects pathspecs that are passed to it, so the fix is simply to pass the pathspec along to the function. Reported-by: Marc Strapetz Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

stash push: avoid printing errors

2018-03-20T16:08:34Z

'git stash push -u -- ' prints the following errors if only matches untracked files: fatal: pathspec 'untracked' did not match any files error: unrecognized input This is because we first clean up the untracked files using 'git clean ', and then use a command chain involving 'git add -u ' and 'git apply' to clear the changes to files that are in the index and were stashed. As the only includes untracked files that were already removed by 'git clean', the 'git add' call will barf, and so will 'git apply', as there are no changes that need to be applied. Fix this by avoiding the 'git clean' if a pathspec is given, and use the pipeline that's used for pathspec mode to get rid of the untracked files as well. Reported-by: Marc Strapetz Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

stash: fix nonsense pipeline

2018-03-20T16:08:34Z

An earlier change bba067d2 ("stash: don't delete untracked files that match pathspec", 2018-01-06) was made by taking a suggestion in a list discussion [1] but did not copy the suggested snippet correctly. And the bug was unnoticed during the review and slipped through. This fixes it. [1] https://public-inbox.org/git/xmqqpo7byjwb.fsf@gitster.mtv.corp.google.com/ Signed-off-by: Junio C Hamano

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

2018-01-23T21:16:39Z

"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