summaryrefslogtreecommitdiff
path: root/git-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-06-25Merge branch 'jk/stash-require-clean-index' into maintLibravatar 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-16Merge branch 'jk/stash-options' into maintLibravatar 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-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-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-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-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>
2012-01-01stash: Don't fail if work dir contains file named 'HEAD'Libravatar Jonathon Mah1-3/+4
When performing a plain "git stash" (without --patch), git-diff would fail with "fatal: ambiguous argument 'HEAD': both revision and filename". The output was piped into git-update-index, masking the failed exit status. The output is now sent to a temporary file (which is cleaned up by existing code), and the exit status is checked. The "HEAD" arg to the git-diff invocation has been disambiguated too, of course. In patch mode, "git stash -p" would fail harmlessly, leaving the working dir untouched. Interactive adding is fine, but the resulting tree was diffed with an ambiguous 'HEAD' argument. Use >foo (no space) when redirecting output. In t3904, checks and operations on each file are in the order they'll appear when interactively staging. In t3905, fix a bug in "stash save --include-untracked -q is quiet": The redirected stdout file was considered untracked, and so was removed from the working directory. Use test path helper functions where appropriate. Signed-off-by: Jonathon Mah <me@JonathonMah.com> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'bc/unstash-clean-crufts'Libravatar Junio C Hamano1-2/+2
* bc/unstash-clean-crufts: git-stash: remove untracked/ignored directories when stashed t/t3905: add missing '&&' linkage git-stash.sh: fix typo in error message t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
2011-08-27git-stash: remove untracked/ignored directories when stashedLibravatar Brandon Casey1-1/+1
The two new stash options --include-untracked and --all do not remove the untracked and/or ignored files that are stashed if those files reside in a subdirectory. e.g. the following sequence fails: mkdir untracked && echo hello >untracked/file.txt && git stash --include-untracked && test ! -f untracked/file.txt Within the git-stash script, git-clean is used to remove the untracked/ignored files, but since the -d option was not supplied, it does not remove directories. So, add -d to the git-clean arguments, and update the tests to test this functionality. Reported-by: Hilco Wijbenga <hilco.wijbenga@gmail.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-27git-stash.sh: fix typo in error messageLibravatar Brandon Casey1-1/+1
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08stash: take advantage of eval_gettextlnLibravatar Jon Seymour1-6/+3
Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-22Merge branch 'dc/stash-con-untracked'Libravatar Junio C Hamano1-5/+65
* dc/stash-con-untracked: stash: Add --include-untracked option to stash and remove all untracked files Conflicts: git-stash.sh
2011-06-26stash: Add --include-untracked option to stash and remove all untracked filesLibravatar David Caldwell1-4/+64
The --include-untracked option acts like the normal "git stash save" but also adds all untracked files in the working directory to the stash and then calls "git clean --force --quiet" to restore the working directory to a pristine state. This is useful for projects that need to run release scripts. With this option, the release scripts can be from the main working directory so one does not have to maintain a "clean" directory in parallel just for releasing. Basically the work-flow becomes: $ git tag release-1.0 $ git stash --include-untracked $ make release $ git clean -f $ git stash pop "git stash" alone is not enough in this case--it leaves untracked files lying around that might mess up a release process that expects everything to be very clean or might let a release succeed that should actually fail (due to a new source file being created that hasn't been committed yet). Signed-off-by: David Caldwell <david@porkrind.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash drop_stash say/die messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Gettextize the say/die eval_gettext messages in the drop_stash function. Since making these translatable would result in a long line I've wrapped this into two lines. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash "unknown option" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+13
Gettextize the "unknown option for 'stash save'" message that's shown on: $ git stash save --blah-blah error: unknown option for 'stash save': --blah-blah To provide a message, use git stash save -- '--blah-blah' Usage: git stash list [<options>] In a translation the second line should be aligned with the first one. I've added a TRANSLATORS comment to indicate this. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + eval_gettext $1 messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+4
Gettextize a messages that used the $1 variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + eval_gettext $* messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+8
Gettextize messages that used the $* variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + eval_gettext messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + gettext messagesLibravatar Ævar Arnfjörð Bjarmason1-18/+18
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash say + gettext messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash echo + gettext messageLibravatar Ævar Arnfjörð Bjarmason1-1/+4
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash add git-sh-i18nLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-04Merge branch 'jk/maint-stash-oob' into maintLibravatar Junio C Hamano1-11/+1
* jk/maint-stash-oob: stash: fix false positive in the invalid ref test. stash: fix accidental apply of non-existent stashes Conflicts: t/t3903-stash.sh
2011-05-04Merge branch 'dm/stash-k-i-p' into maintLibravatar Junio C Hamano1-4/+5
* dm/stash-k-i-p: stash: ensure --no-keep-index and --patch can be used in any order stash: add two more tests for --no-keep-index
2011-04-27Merge branch 'dm/stash-k-i-p'Libravatar Junio C Hamano1-4/+5
* dm/stash-k-i-p: stash: ensure --no-keep-index and --patch can be used in any order stash: add two more tests for --no-keep-index
2011-04-27Merge branch 'jk/maint-stash-oob'Libravatar Junio C Hamano1-11/+1
* jk/maint-stash-oob: stash: fix false positive in the invalid ref test. stash: fix accidental apply of non-existent stashes Conflicts: t/t3903-stash.sh
2011-04-07stash: ensure --no-keep-index and --patch can be used in any orderLibravatar Dan McGee1-4/+5
Don't assume one comes after the other on the command line. Use a three-state variable to track and check its value accordingly. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06stash: drop dirty worktree check on applyLibravatar Jeff King1-3/+1
Before we apply a stash, we make sure there are no changes in the worktree that are not in the index. This check dates back to the original git-stash.sh, and is presumably intended to prevent changes in the working tree from being accidentally lost during the merge. However, this check has two problems: 1. It is overly restrictive. If my stash changes only file "foo", but "bar" is dirty in the working tree, it will prevent us from applying the stash. 2. It is redundant. We don't touch the working tree at all until we actually call merge-recursive. But it has its own (much more accurate) checks to avoid losing working tree data, and will abort the merge with a nicer message telling us which paths were problems. So we can simply drop the check entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05stash: fix accidental apply of non-existent stashesLibravatar Jeff King1-11/+1
Once upon a time, "git rev-parse ref@{9999999}" did not generate an error. Therefore when we got an invalid stash reference in "stash apply", we could end up not noticing until quite late. Commit b0f0ecd (detached-stash: work around git rev-parse failure to detect bad log refs, 2010-08-21) handled this by checking for the "Log for stash has only %d entries" warning on stderr when we validated the ref. A few days later, e6eedc3 (rev-parse: exit with non-zero status if ref@{n} is not valid., 2010-08-24) fixed the original issue. That made the extra stderr test superfluous, but also introduced a new bug. Now the early call to: git rev-parse --symbolic "$@" fails, but we don't notice the exit code. Worse, its empty output means we think the user didn't provide us a ref, and we try to apply stash@{0}. This patch checks the rev-parse exit code and fails early in the revision parsing process. We can also get rid of the stderr test; as a bonus, this means that "stash apply" can now run under GIT_TRACE=1 properly. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-23Merge branch 'pk/stash-apply-status-relative'Libravatar Junio C Hamano1-1/+2
* pk/stash-apply-status-relative: Add test: git stash shows status relative to current dir git stash: show status relative to current directory