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

"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

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 <me@ikke.info>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

If calling git stash -u on a repo that contains a file that is not
ignored any more due to a current modification of the gitignore file,
this file is stashed but not remove from the working tree.
This is due to git-stash first doing a reset --hard which clears the
.gitignore file modification and the call git clean, leaving the file
untouched.
This causes git stash pop to fail due to the file existing.

This patch simply switches the order between cleaning and resetting
and adds a test for this usecase.

Reported-by: Sam Partington <sam@whiteoctober.co.uk>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

We want to make sure that people who copy & paste code would see
fewer instances of "git-foo".  The use of these dashed forms have
been discouraged since v1.6.0 days.

Signed-off-by: Michael Forney <mforney@mforney.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"git status" learned to optionally give how many stash entries the
user has in its output.

* lb/status-stash-count:
  glossary: define 'stash entry'
  status: add optional stash count information
  stash: update documentation to use 'stash entry'

Most of the time, a 'stash entry' is called a 'stash'. Lets try to make
this more consistent and use 'stash entry' instead.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

The `git stash push` command recently gained the ability to get a
pathspec as its argument to only stash matching files. Calling this
command from a subdirectory does not work, though, as one of the first
things we do is changing to the top level directory without keeping
track of the prefix from which the command is being run.

Fix the shortcoming by storing the prefix previous to the call to
`cd_to_toplevel` and then subsequently using `git rev-parse --prefix` to
correctly resolve the pathspec. Add a test to catch future breakage of
this usecase.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Currently when there are untracked changes in a file "one" and in a file
"two" in the repository and the user uses:

    git stash push -k one

all changes in "two" are wiped out completely.  That is clearly not the
intended result.  Make sure that only the files given in the pathspec
are changed when git stash push -k <pathspec> is used.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

For "git stash -p --no-keep-index", the pathspec argument is currently
not passed to "git reset".  This means that changes that are staged but
that are excluded from the pathspec still get unstaged by git stash -p.

Make sure that doesn't happen by passing the pathspec argument to the
git reset in question, bringing the behaviour in line with "git stash --
<pathspec>".

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>