summaryrefslogtreecommitdiff
path: root/git-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-11-19stash: tolerate missing user identityLibravatar Slavica Djukic1-0/+17
The "git stash" command insists on having a usable user identity to the same degree as the "git commit-tree" and "git commit" commands do, because it uses the same codepath that creates commit objects as these commands. It is not strictly necesary to do so. Check if we will barf before creating commit objects and then supply fake identity to please the machinery that creates commits. Add test to document that stash executes correctly both with and without valid ident. This is not that much of usability improvement, as the users who run "git stash" would eventually want to record their changes that are temporarily stored in the stashes in a more permanent history by committing, and they must do "git config user.{name,email}" at that point anyway, so arguably this change is only delaying a step that is necessary to work in the repository. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Slavica Djukic <slawica92@hotmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10Merge branch 'tg/stash-untracked-with-pathspec-fix'Libravatar Junio C Hamano1-6/+8
"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-03-21stash: drop superfluos pathspec parameterLibravatar Thomas Gummerer1-1/+1
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-20stash push -u: don't create empty stashLibravatar Thomas Gummerer1-1/+1
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-20stash push: avoid printing errorsLibravatar Thomas Gummerer1-2/+4
'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-20stash: fix nonsense pipelineLibravatar Junio C Hamano1-3/+3
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-01-23Merge branch 'tg/stash-with-pathspec-fix'Libravatar Junio C Hamano1-3/+2
"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-08stash: don't delete untracked files that match pathspecLibravatar Thomas Gummerer1-3/+2
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>
2017-12-06Merge branch 'ph/stash-save-m-option-fix'Libravatar Junio C Hamano1-0/+18
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-11-24stash: learn to parse -m/--message like commit doesLibravatar Phil Hord1-0/+18
`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-10-27stash: remove now superfluos help for "stash push"Libravatar Thomas Gummerer1-12/+1
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-27stash: replace "git stash save" with "git stash push" in the documentationLibravatar Thomas Gummerer1-5/+5
"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-09-10Merge branch 'mf/no-dashed-subcommands' into maintLibravatar Junio C Hamano1-1/+1
Code clean-up. * mf/no-dashed-subcommands: scripts: use "git foo" not "git-foo"
2017-08-23Merge branch 'kd/stash-with-bash-4.4'Libravatar Junio C Hamano1-2/+9
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-23Merge branch 'nm/stash-untracked'Libravatar Junio C Hamano1-5/+6
"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-14stash: prevent warning about null bytes in inputLibravatar Kevin Daudt1-2/+9
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-11stash: clean untracked files before resetLibravatar Nicolas Morey-Chaisemartin1-5/+6
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-07scripts: use "git foo" not "git-foo"Libravatar Michael Forney1-1/+1
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-06-26Merge branch 'lb/status-stash-count'Libravatar Junio C Hamano1-3/+3
"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-18stash: update documentation to use 'stash entry'Libravatar Liam Beguin1-3/+3
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-13git-stash: fix pushing stash with pathspec from subdirLibravatar Patrick Steinhardt1-0/+3
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-03-22stash: keep untracked files intact in stash -kLibravatar Thomas Gummerer1-1/+3
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-22stash: pass the pathspec argument to git resetLibravatar Thomas Gummerer1-1/+1
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-22stash: don't show internal implementation detailsLibravatar Thomas Gummerer1-4/+4
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-02-28stash: allow pathspecs in the no verb formLibravatar Thomas Gummerer1-0/+3
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-28stash: use stash_push for no verb formLibravatar Thomas Gummerer1-8/+8
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-28stash: teach 'push' (and 'create_stash') to honor pathspecLibravatar Thomas Gummerer1-11/+27
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-19stash: refactor stash_createLibravatar Thomas Gummerer1-4/+18
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-19stash: introduce push verbLibravatar Thomas Gummerer1-3/+43
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-01-17Merge branch 'jk/stash-disable-renames-internally' into maintLibravatar Junio C Hamano1-1/+1
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
2016-12-06stash: prefer plumbing over git-diffLibravatar Jeff King1-1/+1
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-10-26stash: allow stashes to be referenced by index onlyLibravatar Aaron M Watson1-2/+13
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-09-21i18n: stash: mark messages for translationLibravatar Vasco Almeida1-3/+3
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10i18n: git-stash: mark messages for translationLibravatar Vasco Almeida1-2/+2
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: git-sh-setup.sh: mark strings for translationLibravatar Vasco Almeida1-1/+0
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-05-14always quote shell arguments to test -z/-nLibravatar Jeff King1-2/+2
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>
2015-10-05Merge branch 'nk/stash-show-config'Libravatar Junio C Hamano1-1/+19
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-08-31stash: allow "stash show" diff output configurableLibravatar Namhyung Kim1-1/+19
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-07-21git-stash: use update-ref --create-reflog instead of creating filesLibravatar David Turner1-4/+2
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-06-24Merge branch 'jk/stash-require-clean-index'Libravatar Junio C Hamano1-2/+0
A hotfix for the topic already in 'master'. * jk/stash-require-clean-index: Revert "stash: require a clean index to apply"
2015-06-15Revert "stash: require a clean index to apply"Libravatar Jeff King1-2/+0
This reverts commit ed178ef13a26136d86ff4e33bb7b1afb5033f908. 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-01Merge branch 'jk/stash-options'Libravatar Junio C Hamano1-1/+16
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-05-20stash: recognize "--help" for subcommandsLibravatar Jeff King1-0/+11
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-20stash: complain about unknown flagsLibravatar Jeff King1-1/+5
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-19Merge branch 'jk/stash-require-clean-index'Libravatar Junio C Hamano1-0/+2
"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-04-22stash: require a clean index to applyLibravatar Jeff King1-0/+2
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>
2014-12-01git-stash: avoid hardcoding $GIT_DIR/logs/....Libravatar Nguyễn Thái Ngọc Duy1-2/+2
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*.sh: respect $GIT_INDEX_FILELibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Merge branch 'da/rev-parse-verify-quiet'Libravatar Junio C Hamano1-6/+7
"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-19Merge branch 'ah/grammofix'Libravatar Junio C Hamano1-1/+1
* ah/grammofix: grammofix in user-facing messages