summaryrefslogtreecommitdiff
path: root/git-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
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
2014-09-19stash: prefer --quiet over shell redirection of the standard error streamLibravatar David Aguilar1-6/+7
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-09Merge branch 'jk/stash-list-p'Libravatar Junio C Hamano1-1/+1
Teach "git stash list -p" to show the difference between the base commit version and the working tree version, which is in line with what "git show" gives. * jk/stash-list-p: stash: default listing to working-tree diff
2014-09-02grammofix in user-facing messagesLibravatar Alex Henrie1-1/+1
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-07stash: default listing to working-tree diffLibravatar Jeff King1-1/+1
When you list stashes, you can provide arbitrary git-log options to change the display. However, adding just "-p" does nothing, because each stash is actually a merge commit. This implementation detail is easy to forget, leading to confused users who think "-p" is not working. We can make this easier by defaulting to "--first-parent -m", which will show the diff against the working tree. This omits the index portion of the stash entirely, but it's simple and it matches what "git stash show" provides. People who are more clueful about stash's true form can use "--cc" to override the "-m", and the "--first-parent" will then do nothing. For diffs, it only affects non-combined diffs, so "--cc" overrides it. And for the traversal, we are walking the linear reflog anyway, so we do not even care about the parents. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-06Merge branch 'ep/shell-assign-and-export-vars'Libravatar Junio C Hamano1-1/+2
* ep/shell-assign-and-export-vars: scripts: more "export VAR=VALUE" fixes scripts: "export VAR=VALUE" construct is not portable
2014-05-23scripts: "export VAR=VALUE" construct is not portableLibravatar Elia Pinto1-1/+2
Found by check-non-portable-shell.pl Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-23git-stash.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-1/+1
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-03Merge branch 'jc/stash-pop-not-popped' into maintLibravatar Junio C Hamano1-2/+8
* jc/stash-pop-not-popped: stash pop: mention we did not drop the stash upon failing to apply
2014-03-21Merge branch 'jc/stash-pop-not-popped'Libravatar Junio C Hamano1-2/+8
"stash pop", upon failing to apply the stash, refrains from discarding the stash to avoid information loss. Be more explicit in the error message. The wording may want to get a bit more bikeshedding. * jc/stash-pop-not-popped: stash pop: mention we did not drop the stash upon failing to apply
2014-02-26stash pop: mention we did not drop the stash upon failing to applyLibravatar Junio C Hamano1-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07stash: handle specifying stashes with $IFSLibravatar Øystein Walle1-7/+7
When trying to pop/apply a stash specified with an argument containing IFS whitespace, git-stash will throw an error: $ git stash pop 'stash@{two hours ago}' Too many revisions specified: stash@{two hours ago} This happens because word splitting is used to count non-option arguments. Make use of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-14Revert "git stash: avoid data loss when "git stash save" kills a directory"Libravatar Junio C Hamano1-12/+0
This reverts commit a73653130edd6a8977106d45a8092c09040f9132, as it has been reported that "ls-files --killed" is too time-consuming in a deep directory with too many untracked crufts (e.g. $HOME/.git tracking only a few files). We'd need to revisit it later but "ls-files --killed" needs to be optimized before it happens.
2013-07-01git stash: avoid data loss when "git stash save" kills a directoryLibravatar Petr Baudis1-0/+12
"stash save" is about saving the local change to the working tree, but also about restoring the state of the last commit to the working tree. When a local change is to turn a non-directory to a directory, in order to restore the non-directory, everything in the directory needs to be removed. Which is fine when running "git stash save --include-untracked", but without that option, untracked, newly created files in the directory will have to be discarded, if the state you are restoring to has a non-directory at the same path as the directory. Introduce a safety valve to fail the operation in such case, using the "ls-files --killed" which was designed for this exact purpose. The "stash save" is stopped when untracked files need to be discarded because their leading path ceased to be a directory, and the user is required to pass --force to really have the data removed. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17stash: introduce 'git stash store'Libravatar Ramkumar Ramachandra1-6/+41
save_stash() contains the logic for doing two potentially independent operations; the first is preparing the stash merge commit, and the second is updating the stash ref/ reflog accordingly. While the first operation is abstracted out into a create_stash() for callers to access via 'git stash create', the second one is not. Fix this by factoring out the logic for storing the stash into a store_stash() that callers can access via 'git stash store'. Like create, store is not intended for end user interactive use, but for callers in other scripts. We can simplify the logic in the rebase.autostash feature using this new subcommand. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17stash: simplify option parser for createLibravatar Ramkumar Ramachandra1-4/+1
The option parser for create unnecessarily checks "$1" inside a case statement that matches "$1" in the first place. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'ph/stash-rerere'Libravatar Junio C Hamano1-0/+1
"git stash" internally used "git merge-recursive" backend, which did not trigger "rerere" upon conflicts unlike other mergy operations. * ph/stash-rerere: stash: invoke rerere in case of conflict test: git-stash conflict sets up rerere
2012-08-17stash: invoke rerere in case of conflictLibravatar Phil Hord1-0/+1
"stash apply" directly calls a backend merge function which does not automatically invoke rerere. This confuses mergetool when leftover rerere state is left behind from previous merges. Invoke rerere explicitly when we encounter a conflict during stash apply. This turns the test introduced by the previous commit to succeed. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-14stash: use eval_gettextln correctlyLibravatar Ross Lagerwall1-2/+2
Otherwise, passing an invalid option, git stash -v, gave: git-stash: line 204: $'error: unknown option for \'stash save\': $option\n To provide a message, use git stash save -- \'$option\'': command not found Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>