summaryrefslogtreecommitdiff
path: root/t/t3903-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-06-22Merge branch 'ps/stash-push-pathspec-fix'Libravatar Junio C Hamano1-0/+16
"git stash push <pathspec>" did not work from a subdirectory at all. Bugfix for a topic in v2.13 * ps/stash-push-pathspec-fix: git-stash: fix pushing stash with pathspec from subdir
2017-06-13git-stash: fix pushing stash with pathspec from subdirLibravatar Patrick Steinhardt1-0/+16
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-05-11tests: fix tests broken under GETTEXT_POISON=YesPleaseLibravatar Ævar Arnfjörð Bjarmason1-2/+2
The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on the list ("[BUG] test suite broken with GETTEXT_POISON=YesPlease", [1]) asking whether this mode was useful at all anymore. At least one person occasionally uses it, and Lars Schneider offered to change one of the the Travis builds to run in this mode, so fix up the failing ones. My test setup runs most of the tests, with the notable exception of skipping all the p4 tests, so it's possible that there's still some lurking regressions I haven't fixed. 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-22stash: keep untracked files intact in stash -kLibravatar Thomas Gummerer1-0/+14
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: don't show internal implementation detailsLibravatar Thomas Gummerer1-1/+1
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/+15
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-3/+1
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-0/+92
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: add test for the create command line argumentsLibravatar Thomas Gummerer1-0/+18
Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. 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-0/+9
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-0/+9
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-0/+9
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-0/+35
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>
2015-07-28tests: remove some direct access to .git/logsLibravatar David Turner1-1/+1
Alternate refs backends might store reflogs somewhere other than .git/logs. Change most test code that directly accesses .git/logs to instead use git reflog commands. There are still a few tests which need direct access to reflogs: to check reflog permissions, to manually create reflogs from scratch, to save/restore reflogs, to check the format of raw reflog data, and to remove not just reflog contents, but the reflogs themselves. All cases which don't need direct access have been modified. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25Merge branch 'jk/stash-require-clean-index' into maintLibravatar Junio C Hamano1-7/+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-0/+4
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-7/+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: complain about unknown flagsLibravatar Jeff King1-0/+4
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/+7
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-22t3903: avoid applying onto dirty indexLibravatar Jeff King1-2/+2
One of the tests in t3903 wants to make sure that applying a stash that touches only "file" can still happen even if there are working tree changes to "other-file". To do so, it adds "other-file" to the index (since otherwise it is an untracked file, voiding the purpose of the test). But as we are about to refactor the dirty-index handling, and as this test does not actually care about having a dirty index (only a dirty working tree), let's bump the tracking of "other-file" into the setup phase, so we can have _just_ a dirty working tree here. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-22t3903: stop hard-coding commit sha1sLibravatar Jeff King1-5/+5
When testing the diff output of "git stash list", we look for the stash's subject of "WIP on master: $sha1", even though it's not relevant to the diff output. This makes the test brittle to refactoring, as any changes to earlier tests may impact the commit sha1. Since we don't care about the commit subject here, we can simply ask stash not to print it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-07stash: default listing to working-tree diffLibravatar Jeff King1-0/+42
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-01-07stash: handle specifying stashes with $IFSLibravatar Øystein Walle1-0/+12
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-18/+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/+18
"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-27Merge branch 'rr/rebase-stash-store'Libravatar Junio C Hamano1-0/+19
Finishing touches for the "git rebase --autostash" feature introduced earlier. * rr/rebase-stash-store: rebase: use 'git stash store' to simplify logic stash: introduce 'git stash store' stash: simplify option parser for create stash doc: document short form -p in synopsis stash doc: add a warning about using create
2013-06-20Merge branch 'fc/show-non-empty-errors-in-test'Libravatar Junio C Hamano1-5/+5
* fc/show-non-empty-errors-in-test: test: test_must_be_empty helper
2013-06-17stash: introduce 'git stash store'Libravatar Ramkumar Ramachandra1-0/+19
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-09test: test_must_be_empty helperLibravatar Junio C Hamano1-5/+5
There are quite a lot places where an output file is expected to be empty, and we fail the test when it is not. The output from running the test script with -i -v can be helped if we showed the unexpected contents at that point. We could of course do >expected.empty && test_cmp expected.empty actual but this is commmon enough to be done with a dedicated helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)Libravatar Johannes Sixt1-11/+28
There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on git-stashLibravatar Jiang Xin1-1/+1
Use i18n-specific test functions in test scripts for git-stash. This issue was was introduced in v1.7.4.1-119-g355ec: 355ec i18n: git-status basic messages and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-30diff --stat: use less columns for change countsLibravatar Zbigniew Jędrzejewski-Szmek1-1/+1
Number of columns required for change counts is now computed based on the maximum number of changed lines instead of being fixed. This means that usually a few more columns will be available for the filenames and the graph. The graph width logic is also modified to include enough space for "Bin XXX -> YYY bytes". If changes to binary files are mixed with changes to text files, change counts are padded to take at least three columns. And the other way around, if change counts require more than three columns, then "Bin"s are padded to align with the change count. This way, the +- part starts in the same column as "XXX -> YYY" part for binary files. This makes the graph easier to parse visually thanks to the empty column. This mimics the layout of diff --stat before this change. Tests and the tutorial are updated to reflect the new --stat output. This means either the removal of extra padding and/or the addition of up to three extra characters to truncated filenames. One test is added to check the graph alignment when a binary file change and text file change of more than 999 lines are committed together. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13test: use --numstat instead of --stat in "git stash show" testsLibravatar Jonathan Nieder1-7/+19
git's diff --stat output is intended for human consumption and since v1.7.9.2~13 (2012-02-01) varies by locale. Add a test checking that git stash show defaults to --stat and tweak the rest of the "stash show" tests that showed a diffstat to use numstat. This way, there are fewer tests to tweak if the diffstat format changes again. This also improves test coverage when running tests with git configured not to write its output in the C locale (e.g., via GETTEXT_POISON=Yes). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13test: use test_i18ncmp when checking --stat outputLibravatar Jonathan Nieder1-2/+2
Ever since v1.7.9.2~13 (2012-02-01), git's diffstat-style summary line produced by "git apply --stat", "git diff --stat", and "git commit" varies by locale, producing test failures when GETTEXT_POISON is set. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03Use correct grammar in diffstat summary lineLibravatar Nguyễn Thái Ngọc Duy1-2/+2
"git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@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-0/+24
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-09-02Merge branch 'tr/maint-t3903-misquoted-command'Libravatar Junio C Hamano1-1/+1
* tr/maint-t3903-misquoted-command: t3903: fix misquoted rev-parse invocation
2011-08-30t3903: fix misquoted rev-parse invocationLibravatar Thomas Rast1-1/+1
!"git ..." hopefully always succeeds because "git ..." is not the name of any executable. However, that's not what was intended. Unquote it, and while we're at it, also replace ! with test_must_fail since it is a call to git. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16Fix typo: existant->existentLibravatar Dmitry Ivankov1-1/+1
refs.c had a error message "Trying to write ref with nonexistant object". And no tests relied on the wrong spelling. Also typo was present in some test scripts internals, these tests still pass. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-27Merge branch 'dm/stash-k-i-p'Libravatar Junio C Hamano1-0/+8
* 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-5/+11
* 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: add two more tests for --no-keep-indexLibravatar Dan McGee1-0/+8
One of these passes just fine; the other one exposes a problem where command line flag order matters for --no-keep-index and --patch interaction. 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-4/+16
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 false positive in the invalid ref test.Libravatar Jon Seymour1-5/+5
Jeff King reported a problem with git stash apply incorrectly applying an invalid stash reference. There is an existing test that should have caught this, but the test itself was broken, resulting in a false positive. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05stash: fix accidental apply of non-existent stashesLibravatar Jeff King1-0/+6
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-20Add test: git stash shows status relative to current dirLibravatar Piotr Krukowiecki1-0/+19
[jc: moved "cd subdir" inside subshell and fixed comparison with expected] Signed-off-by: Piotr Krukowiecki <piotr.krukowiecki@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-3/+3
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29stash: fix git stash branch regression when branch creation failsLibravatar Jon Seymour1-1/+1
"git stash branch <branch> <stash>" started discarding the stash when the branch creation fails. It should have kept the stash intact when aborting. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29stash drops the stash even if creating the branch fails because it already ↵Libravatar Tomas Carnecky1-0/+11
exists This bug was disovered by someone on IRC when he tried to $ git stash branch <branch> <stash> while <branch> already existed. In that case the stash is dropped even though it isn't applied on any branch, so the stash is effectively lost. Signed-off-by: Tomas Carnecky <tom@dbservice.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-26git-stash: fix flag parsingLibravatar Brian Gernhardt1-4/+4
Currently git-stash uses `git rev-parse --no-revs -- "$@"` to set its FLAGS variable. This is the same as `FLAGS="-- $@"`. It should use `git rev-parse --no-revs --flags "$@"`, but that eats any "-q" or "--quiet" argument. So move the check for quiet before rev-parse. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>