summaryrefslogtreecommitdiff
path: root/t/t3903-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-01-23Merge branch 'tg/stash-with-pathspec-fix'Libravatar Junio C Hamano1-0/+32
"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-0/+32
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/+93
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/+93
`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-08-19stash: add a test for stashing in a detached stateLibravatar Joel Teichroeb1-0/+12
All that we are really testing here is that the message is correct when we are not on any branch. All other functionality is already tested elsewhere. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19stash: add a test for when apply fails during stash branchLibravatar Joel Teichroeb1-0/+14
If the return value of merge recursive is not checked, the stash could end up being dropped even though it was not applied properly Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19stash: add a test for stash create with no filesLibravatar Joel Teichroeb1-0/+8
Ensure the command suceeds and outputs nothing Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>