Граф коммитов

174 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano cbf0339439 Merge branch 'tg/stash-untracked-with-pathspec-fix'
"git stash push -u -- <pathspec>" gave an unnecessary and confusing
error message when there was no tracked files that match the
<pathspec>, 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
2018-04-10 08:25:45 +09:00
Thomas Gummerer 353278687e stash: drop superfluos pathspec parameter
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 <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-21 15:07:46 -07:00
Thomas Gummerer d319bb18b1 stash push -u: don't create empty stash
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 --
<non-existant>' 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 <marc.strapetz@syntevo.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-20 09:08:34 -07:00
Thomas Gummerer 833622a945 stash push: avoid printing errors
'git stash push -u -- <pathspec>' prints the following errors if
<pathspec> 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
<pathspec>', and then use a command chain involving 'git add -u
<pathspec>' and 'git apply' to clear the changes to files that are in
the index and were stashed.

As the <pathspec> 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 <marc.strapetz@syntevo.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-20 09:08:34 -07:00
Junio C Hamano d97e4fa748 stash: fix nonsense pipeline
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 <gitster@pobox.com>
2018-03-20 09:08:34 -07:00
Junio C Hamano 087d1a8e9c Merge branch 'tg/stash-with-pathspec-fix'
"git stash -- <pathspec>" 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
2018-01-23 13:16:39 -08:00
Thomas Gummerer bba067d2fa stash: don't delete untracked files that match pathspec
Currently when 'git stash push -- <pathspec>' 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 <pathspec>
&& git ls-files --modified <pathspec> | git checkout-index && git clean
<pathspec>'.

The intention was to emulate what 'git reset --hard -- <pathspec>' 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 --
<pathspec>'.  However if <pathspec> 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 <reid.price@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08 13:02:25 -08:00
Junio C Hamano 714485c7de Merge branch 'ph/stash-save-m-option-fix'
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
2017-12-06 09:23:43 -08:00
Phil Hord 5675473fcb stash: learn to parse -m/--message like commit does
`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 <phil.hord@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24 14:47:44 +09:00
Thomas Gummerer c0c0c825ce stash: remove now superfluos help for "stash push"
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
"-- --<pathspec>".  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 <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-27 09:59:11 +09:00
Thomas Gummerer db37745eef stash: replace "git stash save" with "git stash push" in the documentation
"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 <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-27 09:58:38 +09:00
Junio C Hamano 036e1274a2 Merge branch 'mf/no-dashed-subcommands' into maint
Code clean-up.

* mf/no-dashed-subcommands:
  scripts: use "git foo" not "git-foo"
2017-09-10 17:02:56 +09:00
Junio C Hamano ef9408cfb5 Merge branch 'kd/stash-with-bash-4.4'
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
2017-08-23 14:13:08 -07:00
Junio C Hamano 0ca2f3241a Merge branch 'nm/stash-untracked'
"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
2017-08-23 14:13:07 -07:00
Kevin Daudt 5fc92f8828 stash: prevent warning about null bytes in input
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>
2017-08-14 15:35:48 -07:00
Nicolas Morey-Chaisemartin bbffd87d32 stash: clean untracked files before reset
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>
2017-08-11 15:11:30 -07:00
Michael Forney 974ce8078c scripts: use "git foo" not "git-foo"
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>
2017-08-07 12:04:45 -07:00
Junio C Hamano 849b44cdf1 Merge branch 'lb/status-stash-count'
"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'
2017-06-26 14:09:29 -07:00
Liam Beguin e01db917d8 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>
2017-06-18 22:16:36 -07:00
Patrick Steinhardt 22fc703ec9 git-stash: fix pushing stash with pathspec from subdir
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>
2017-06-13 08:27:13 -07:00
Thomas Gummerer e0e7f99ea4 stash: keep untracked files intact in stash -k
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>
2017-03-22 14:55:56 -07:00
Thomas Gummerer 869fb8f729 stash: pass the pathspec argument to git reset
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>
2017-03-22 14:55:55 -07:00
Thomas Gummerer 1790f4fea0 stash: don't show internal implementation details
git stash push uses other git commands internally.  Currently it only
passes the -q flag to those if the -q flag is passed to git stash.  when
using 'git stash push -p -q --no-keep-index', it doesn't even pass the
flag on to the internal reset at all.

It really is enough for the user to know that the stash is created,
without bothering them with the internal details of what's happening.
Always pass the -q flag to the internal git clean and git reset
commands, to avoid unnecessary and potentially confusing output.

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>
2017-03-22 14:55:11 -07:00
Thomas Gummerer 9e140909f6 stash: allow pathspecs in the no verb form
Now that stash_push is used in the no verb form of stash, allow
specifying the command line for this form as well.  Always use -- to
disambiguate pathspecs from other non-option arguments.

Also make git stash -p an alias for git stash push -p.  This allows
users to use git stash -p <pathspec>.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28 14:21:10 -08:00
Thomas Gummerer 1ada5020b3 stash: use stash_push for no verb form
Now that we have stash_push, which accepts pathspec arguments, use
it instead of stash_save in git stash without any additional verbs.

Previously we allowed git stash -- -message, which is no longer allowed
after this patch.  Messages starting with a hyphen was allowed since
3c2eb80f, ("stash: simplify defaulting to "save" and reject unknown
options").  However it was never the intent to allow that, but rather it
was allowed accidentally.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28 14:21:10 -08:00
Thomas Gummerer df6bba0937 stash: teach 'push' (and 'create_stash') to honor pathspec
While working on a repository, it's often helpful to stash the changes
of a single or multiple files, and leave others alone.  Unfortunately
git currently offers no such option.  git stash -p can be used to work
around this, but it's often impractical when there are a lot of changes
over multiple files.

Allow 'git stash push' to take pathspec to specify which paths to stash.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28 14:21:05 -08:00
Thomas Gummerer 9ca6326dff stash: refactor stash_create
Refactor the internal stash_create function to use a -m flag for
specifying the message and -u flag to indicate whether untracked files
should be added to the stash.

This makes it easier to pass a pathspec argument to stash_create in the
next patch.

The user interface for git stash create stays the same.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-19 23:47:41 -08:00
Thomas Gummerer f5727e26e4 stash: introduce push verb
Introduce a new git stash push verb in addition to git stash save.  The
push verb is used to transition from the current command line arguments
to a more conventional way, in which the message is given as an argument
to the -m option.

This allows us to have pathspecs at the end of the command line
arguments like other Git commands do, so that the user can say which
subset of paths to stash (and leave others behind).

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-19 23:47:41 -08:00
Junio C Hamano 12361d025f Merge branch 'jk/stash-disable-renames-internally' into maint
When diff.renames configuration is on (and with Git 2.9 and later,
it is enabled by default, which made it worse), "git stash"
misbehaved if a file is removed and another file with a very
similar content is added.

* jk/stash-disable-renames-internally:
  stash: prefer plumbing over git-diff
2017-01-17 14:49:30 -08:00
Jeff King 9d4e28ead5 stash: prefer plumbing over git-diff
When creating a stash, we need to look at the diff between
the working tree and HEAD, and do so using the git-diff
porcelain.  Because git-diff enables porcelain config like
renames by default, this causes at least one problem. The
--name-only format will not mention the source side of a
rename, meaning we will fail to stash a deletion that is
part of a rename.

We could fix that case by passing --no-renames, but this is
a symptom of a larger problem. We should be using the
diff-index plumbing here, which does not have renames
enabled by default, and also does not respect any
potentially confusing config options.

Reported-by: Matthew Patey <matthew.patey2167@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06 14:16:53 -08:00
Aaron M Watson a56c8f5aab stash: allow stashes to be referenced by index only
Instead of referencing "stash@{n}" explicitly, make it possible to
simply reference as "n".  Most users only reference stashes by their
position in the stash stack (what I refer to as the "index" here).

The syntax for the typical stash (stash@{n}) is slightly annoying and
easy to forget, and sometimes difficult to escape properly in a
script. Because of this the capability to do things with the stash by
simply referencing the index is desirable.

This patch includes the superior implementation provided by Øsse Walle
(thanks for that), with a slight change to fix a broken test in the test
suite. I also merged the test scripts as suggested by Jeff King, and
un-wrapped the documentation as suggested by Junio Hamano.

Signed-off-by: Aaron M Watson <watsona4@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
2016-10-26 09:58:10 -07:00
Vasco Almeida 850251f33b i18n: stash: mark messages for translation
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-21 10:20:43 -07:00
Vasco Almeida 599e7a0b9e i18n: git-stash: mark messages for translation
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10 10:50:18 -07:00
Vasco Almeida d323c6b641 i18n: git-sh-setup.sh: mark strings for translation
Positional arguments, such as $0, $1, etc, need to be stored on shell
variables for use in translatable strings, according to gettext manual
[1].

Add git-sh-setup.sh to LOCALIZED_SH variable in Makefile to enable
extraction of string marked for translation by xgettext.

Source git-sh-i18n in git-sh-setup.sh for gettext support.
git-sh-setup.sh is a shell library to be sourced by other shell scripts.
In order to avoid other scripts from sourcing git-sh-i18n twice, remove
line that sources it from them.  Not sourcing git-sh-i18n in any script
that uses gettext would lead to failure due to, for instance, gettextln
not being found.

[1] http://www.gnu.org/software/gettext/manual/html_node/Preparing-Shell-Scripts.html

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 15:45:48 -07:00
Jeff King 268ef4d3d0 always quote shell arguments to test -z/-n
In shell code like:

  test -z $foo
  test -n $foo

that does not quote its arguments, it's easy to think that
it is actually looking at the contents of $foo in each case.
But if $foo is empty, then "test" does not see any argument
at all! The results are quite subtle.

POSIX specifies that test's behavior depends on the number
of arguments it sees, and if $foo is empty, it sees only
one. The behavior in this case is:

  1 argument: Exit true (0) if $1 is not null; otherwise,
              exit false.

So in the "-z $foo" case, if $foo is empty, then we check
that "-z" is non-null, and it returns success. Which happens
to match what we expected.  But for "-n $foo", if $foo is
empty, we'll see that "-n" is non-null and still return
success. That's the opposite of what we intended!

Furthermore, if $foo contains whitespace, we'll end up with
more than 2 arguments. The results in this case are
generally unspecified (unless the first part of $foo happens
to be a valid binary operator, in which case the results are
specified but certainly not what we intended).

And on top of this, even though "test -z $foo" _should_ work
for the empty case, some older shells (reportedly ksh88)
complain about the missing argument.

So let's make sure we consistently quote our variable
arguments to "test". After this patch, the results of:

  git grep 'test -[zn] [^"]'

are empty.

Reported-by: Armin Kunaschik <megabreit@googlemail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-14 10:37:29 -07:00
Junio C Hamano 5e9a74b480 Merge branch 'nk/stash-show-config'
Users who are too busy to type three extra keystrokes to ask for
"git stash show -p" can now set stash.showPatch configuration
varible to true to always see the actual patch, not just the list
of paths affected with feel for the extent of damage via diffstat.

* nk/stash-show-config:
  stash: allow "stash show" diff output configurable
2015-10-05 12:30:10 -07:00
Namhyung Kim 3086c064fb stash: allow "stash show" diff output configurable
Some users might want to see diff (patch) output always rather than
diffstat when [s]he runs 'git stash show'.  Although this can be
done with adding -p option, users are too lazy to type extra three
keys.

Add two variables that control to show diffstat and patch output
respectively.  The stash.showStat is for diffstat and default is
true.  The stat.showPatch is for the patch output and default is
false.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31 11:29:04 -07:00
David Turner 89dea97334 git-stash: use update-ref --create-reflog instead of creating files
This is in support of alternate ref backends which don't necessarily
store reflogs as files.

Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-21 14:08:49 -07:00
Junio C Hamano bfb539bb73 Merge branch 'jk/stash-require-clean-index'
A hotfix for the topic already in 'master'.

* jk/stash-require-clean-index:
  Revert "stash: require a clean index to apply"
2015-06-24 12:21:59 -07:00
Jeff King 19376104a8 Revert "stash: require a clean index to apply"
This reverts commit ed178ef13a.

That commit was an attempt to improve the safety of applying
a stash, because the application process may create
conflicted index entries, after which it is hard to restore
the original index state.

Unfortunately, this hurts some common workflows around "git
stash -k", like:

    git add -p       ;# (1) stage set of proposed changes
    git stash -k     ;# (2) get rid of everything else
    make test        ;# (3) make sure proposal is reasonable
    git stash apply  ;# (4) restore original working tree

If you "git commit" between steps (3) and (4), then this
just works. However, if these steps are part of a pre-commit
hook, you don't have that opportunity (you have to restore
the original state regardless of whether the tests passed or
failed).

It's possible that we could provide better tools for this
sort of workflow. In particular, even before ed178ef, it
could fail with a conflict if there were conflicting hunks
in the working tree and index (since the "stash -k" puts the
index version into the working tree, and we then attempt to
apply the differences between HEAD and the old working tree
on top of that). But the fact remains that people have been
using it happily for a while, and the safety provided by
ed178ef is simply not that great. Let's revert it for now.
In the long run, people can work on improving stash for this
sort of workflow, but the safety tradeoff is not worth it in
the meantime.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-15 13:11:17 -07:00
Junio C Hamano f693bb0bb0 Merge branch 'jk/stash-options'
Make "git stash something --help" error out, so that users can
safely say "git stash drop --help".

* jk/stash-options:
  stash: recognize "--help" for subcommands
  stash: complain about unknown flags
2015-06-01 12:45:14 -07:00
Jeff King 5ba28313f2 stash: recognize "--help" for subcommands
If you run "git stash --help", you get the help for stash
(this magic is done by the git wrapper itself). But if you
run "git stash drop --help", you get an error. We
cannot show help specific to "stash drop", of course, but we
can at least give the user the normal stash manpage.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-20 13:47:41 -07:00
Jeff King d6cc2df5c8 stash: complain about unknown flags
The option parser for git-stash stuffs unknown flags into
the $FLAGS variable, where they can be accessed by the
individual commands. However, most commands do not even look
at these extra flags, leading to unexpected results like
this:

  $ git stash drop --help
  Dropped refs/stash@{0} (e6cf6d80faf92bb7828f7b60c47fc61c03bd30a1)

We should notice the extra flags and bail. Rather than
annotate each command to reject a non-empty $FLAGS variable,
we can notice that "stash show" is the only command that
actually _wants_ arbitrary flags. So we switch the default
mode to reject unknown flags, and let stash_show() opt into
the feature.

Reported-by: Vincent Legoll <vincent.legoll@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-20 13:47:30 -07:00
Junio C Hamano 05c39674f3 Merge branch 'jk/stash-require-clean-index'
"git stash pop/apply" forgot to make sure that not just the working
tree is clean but also the index is clean. The latter is important
as a stash application can conflict and the index will be used for
conflict resolution.

* jk/stash-require-clean-index:
  stash: require a clean index to apply
  t3903: avoid applying onto dirty index
  t3903: stop hard-coding commit sha1s
2015-05-19 13:17:52 -07:00
Jeff King ed178ef13a stash: require a clean index to apply
If you have staged contents in your index and run "stash
apply", we may hit a conflict and put new entries into the
index. Recovering to your original state is difficult at
that point, because tools like "git reset --keep" will blow
away anything staged.  We can make this safer by refusing to
apply when there are staged changes.

It's possible we could provide better tooling here, as "git
stash apply" should be writing only conflicts to the index
(so we know that any stage-0 entries are potentially
precious). But it is the odd duck; most "mergy" commands
will update the index for cleanly merged entries, and it is
not worth updating our tooling to support this use case
which is unlikely to be of interest (besides which, we would
still need to block a dirty index for "stash apply --index",
since that case _would_ be ambiguous).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-22 13:38:58 -07:00
Nguyễn Thái Ngọc Duy 337959b491 git-stash: avoid hardcoding $GIT_DIR/logs/....
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01 11:00:14 -08:00
Nguyễn Thái Ngọc Duy c697b577a2 *.sh: respect $GIT_INDEX_FILE
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01 11:00:12 -08:00
Junio C Hamano 507fe835ed Merge branch 'da/rev-parse-verify-quiet'
"rev-parse --verify --quiet $name" is meant to quietly exit with a
non-zero status when $name is not a valid object name, but still
gave error messages in some cases.

* da/rev-parse-verify-quiet:
  stash: prefer --quiet over shell redirection of the standard error stream
  refs: make rev-parse --quiet actually quiet
  t1503: use test_must_be_empty
  Documentation: a note about stdout for git rev-parse --verify --quiet
2014-09-29 12:36:10 -07:00
Junio C Hamano 296b4c4bbf Merge branch 'ah/grammofix'
* ah/grammofix:
  grammofix in user-facing messages
2014-09-19 11:38:35 -07:00
David Aguilar 1956dfa818 stash: prefer --quiet over shell redirection of the standard error stream
Use `git rev-parse --verify --quiet` instead of redirecting
stderr to /dev/null.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-19 10:51:59 -07:00