summaryrefslogtreecommitdiff
path: root/t/t3903-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
2022-03-16Merge branch 'jc/stash-drop'Libravatar Junio C Hamano1-1/+42
"git stash drop" is reimplemented as an internal call to reflog_delete() function, instead of invoking "git reflog delete" via run_command() API. * jc/stash-drop: stash: call reflog_delete() in reflog.c reflog: libify delete reflog function and helpers stash: add tests to ensure reflog --rewrite --updatref behavior
2022-03-06Merge branch 'gc/stash-on-branch-with-multi-level-name'Libravatar Junio C Hamano1-0/+11
"git checkout -b branch/with/multi/level/name && git stash" only recorded the last level component of the branch name, which has been corrected. * gc/stash-on-branch-with-multi-level-name: stash: strip "refs/heads/" with skip_prefix
2022-03-06Merge branch 'cg/t3903-modernize'Libravatar Junio C Hamano1-9/+12
Test modernization. * cg/t3903-modernize: tests: make the code more readable tests: allow testing if a path is truly a file or a directory t/t3903-stash.sh: replace test [-d|-f] with test_path_is_*
2022-03-02stash: add tests to ensure reflog --rewrite --updatref behaviorLibravatar John Cai1-1/+42
There is missing test coverage to ensure that the resulting reflogs after a git stash drop has had its old oid rewritten if applicable, and if the refs/stash has been updated if applicable. Add two tests that verify both of these happen. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-24stash: strip "refs/heads/" with skip_prefixLibravatar Glen Choo1-0/+11
When generating a message for a stash, "git stash" only records the part of the branch name to the right of the last "/". e.g. if HEAD is at "foo/bar/baz", "git stash" generates a message prefixed with "WIP on baz:" instead of "WIP on foo/bar/baz:". Fix this by using skip_prefix() to skip "refs/heads/" instead of looking for the last instance of "/". Reported-by: Kraymer <kraymer@gmail.com> Reported-by: Daniel Hahler <git@thequod.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23tests: make the code more readableLibravatar COGONI Guillaume1-3/+6
Replace the parsing of the output of "ls -l" by test_path_is_symlink() and test_readlink(). Signed-off-by: COGONI Guillaume <cogoni.guillaume@gmail.com> Co-authored-by: BRESSAT Jonathan <git.jonathan.bressat@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23tests: allow testing if a path is truly a file or a directoryLibravatar COGONI Guillaume1-3/+3
Add test_path_is_file_not_symlink(), test_path_is_dir_not_symlink() and test_path_is_symlink(). Case of use for the first one in test t/t3903-stash.sh to replace "test -f" because that function explicitly want the file not to be a symlink. Give more friendly error message. Signed-off-by: COGONI Guillaume <cogoni.guillaume@gmail.com> Co-authored-by: BRESSAT Jonathan <git.jonathan.bressat@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23t/t3903-stash.sh: replace test [-d|-f] with test_path_is_*Libravatar COGONI Guillaume1-3/+3
Use test_path_is_* to replace test [-d|-f] because that give more explicit debugging information. And it doesn't change the semantics. Signed-off-by: COGONI Guillaume <cogoni.guillaume@gmail.com> Co-authored-by: BRESSAT Jonathan <git.jonathan.bressat@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-27stash: stop warning about the obsolete `stash.useBuiltin` config settingLibravatar Johannes Schindelin1-15/+0
In 8a2cd3f5123 (stash: remove the stash.useBuiltin setting, 2020-03-03), we removed support for `stash.useBuiltin`, but left a warning in its place. After almost two years, and several major versions, it is time to remove even that warning. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10Merge branch 'en/stash-df-fix'Libravatar Junio C Hamano1-0/+24
"git stash apply" forgot to attempt restoring untracked files when it failed to restore changes to tracked ones. * en/stash-df-fix: stash: do not return before restoring untracked files
2022-01-10Merge branch 'ab/do-not-limit-stash-help-to-push'Libravatar Junio C Hamano1-0/+19
"git stash" by default triggers its "push" action, but its implementation also made "git stash -h" to show short help only for "git stash push", which has been corrected. * ab/do-not-limit-stash-help-to-push: stash: don't show "git stash push" usage on bad "git stash" usage
2022-01-04stash: do not return before restoring untracked filesLibravatar Elijah Newren1-0/+24
In commit bee8691f19 ("stash: restore untracked files AFTER restoring tracked files", 2021-09-10), we correctly identified that we should restore changes to tracked files before attempting to restore untracked files, and accordingly moved the code for restoring untracked files a few lines down in do_apply_stash(). Unfortunately, the intervening lines had some early return statements meaning that we suddenly stopped restoring untracked files in some cases. Even before the previous commit, there was another possible issue with the current code -- a post-stash-apply 'git status' that was intended to be run after restoring the stash was skipped when we hit a conflict (or other error condition), which seems slightly inconsistent. Fix both issues by saving the return status, and letting other functionality run before returning. Reported-by: AJ Henderson Test-case-by: Randall S. Becker <randall.becker@nexbridge.ca> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-16stash: don't show "git stash push" usage on bad "git stash" usageLibravatar Ævar Arnfjörð Bjarmason1-0/+19
Change the usage message emitted by "git stash --invalid-option" to emit usage information for "git stash" in general, and not just for the "push" command. I.e. before: $ git stash --invalid-option error: unknown option `invalid-option' usage: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [-m|--message <message>] [--] [<pathspec>...]] [...] After: $ git stash --invalid-option error: unknown option `invalid-option' usage: git stash list [<options>] or: git stash show [<options>] [<stash>] or: git stash drop [-q|--quiet] [<stash>] or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>] or: git stash branch <branchname> [<stash>] or: git stash clear or: git stash [push [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [-m|--message <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]] or: git stash save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [<message>] [...] That we emitted the usage for just "push" in the case of the subcommand not being explicitly specified was an unintentional side-effect of how it was implemented. When it was converted to C in d553f538b8a (stash: convert push to builtin, 2019-02-25) the pattern of having per-subcommand usage information was rightly continued. The "git-stash.sh" shellscript did not have that, and always printed the equivalent of "git_stash_usage". But in doing so the case of push being implicit and explicit was conflated. A variable was added to track this in 8c3713cede7 (stash: eliminate crude option parsing, 2020-02-17), but it did not update the usage output accordingly. This still leaves e.g. "git stash push -h" emitting the "git_stash_usage" output, instead of "git_stash_push_usage". That should be fixed, but is a much deeper misbehavior in parse_options() not being aware of subcommands at all. I.e. in how PARSE_OPT_KEEP_UNKNOWN and PARSE_OPT_NO_INTERNAL_HELP combine in commands such as "git stash". Perhaps PARSE_OPT_KEEP_UNKNOWN should imply PARSE_OPT_NO_INTERNAL_HELP, or better yet parse_options() should be extended to fully handle these subcommand cases that we handle manually in "git stash", "git commit-graph", "git multi-pack-index" etc. All of those musings would be a much bigger change than this isolated fix though, so let's leave that for some other time. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18stash: implement '--staged' option for 'push' and 'save'Libravatar Sergey Organov1-0/+11
Stash only the changes that are staged. This mode allows to easily stash-out for later reuse some changes unrelated to the current work in progress. Unlike 'stash push --patch', --staged supports use of any tool to select the changes to stash-out, including, but not limited to 'git add --interactive'. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10stash: restore untracked files AFTER restoring tracked filesLibravatar Elijah Newren1-2/+2
If a user deletes a file and places a directory of untracked files there, then stashes all these changes, the untracked directory of files cannot be restored until after the corresponding file in the way is removed. So, restore changes to tracked files before restoring untracked files. There is no counterpart problem to worry about with the user deleting an untracked file and then add a tracked one in its place. Git does not track untracked files, and so will not know the untracked file was deleted, and thus won't be able to stash the removal of that file. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10stash: avoid feeding directories to update-indexLibravatar Elijah Newren1-1/+1
When a file is removed from the cache, but there is a file of the same name present in the working directory, we would normally treat that file in the working directory as untracked. However, in the case of stash, doing that would prevent a simple 'git stash push', because the untracked file would be in the way of restoring the deleted file. git stash, however, blindly assumes that whatever is in the working directory for a deleted file is wanted and passes that path along to update-index. That causes problems when the working directory contains a directory with the same name as the deleted file. Add some code for this special case that will avoid passing directory names to update-index. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10t3903: document a pair of directory/file bugsLibravatar Elijah Newren1-0/+58
There are three tests here, because the second bug is documented with two tests: a file -> directory change and a directory -> file change. The reason for the two tests is just to verify that both are indeed broken but that both will be fixed by the same simple change (which will be provided in a subsequent patch). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21stash list: stop passing "-m" to "git log"Libravatar Sergey Organov1-1/+1
Passing "-m" in "git log --first-parent -m" is not needed as --first-parent implies --diff-merges=first-parent anyway. OTOH, it will stop being harmless once we let "-m" imply "-p". While we are at it, fix corresponding test description in t3903-stash to match what it actually tests. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-10tests: remove most uses of test_i18ncmpLibravatar Ævar Arnfjörð Bjarmason1-4/+4
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t3[5-9]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-17/+17
This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t3[5-9]*.sh) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-26Merge branch 'tg/retire-scripted-stash'Libravatar Junio C Hamano1-0/+14
"git stash" has kept an escape hatch to use the scripted version for a few releases, which got stale. It has been removed. * tg/retire-scripted-stash: stash: remove the stash.useBuiltin setting stash: get git_stash_config at the top level
2020-03-05stash: remove the stash.useBuiltin settingLibravatar Thomas Gummerer1-0/+14
Remove the stash.useBuiltin setting which was added as an escape hatch to disable the builtin version of stash first released with Git 2.22. Carrying the legacy version is a maintenance burden, and has in fact become out of date failing a test since the 2.23 release, without anyone noticing until now. So users would be getting a hint to fall back to a potentially buggy version of the tool. We used to shell out to git config to get the useBuiltin configuration to avoid changing any global state before spawning legacy-stash. However that is no longer necessary, so just use the 'git_config' function to get the setting instead. Similar to what we've done in d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18), where we remove the corresponding setting for rebase, we leave the documentation in place, so people can refer back to it when searching for it online, and so we can refer to it in the commit message. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19stash: eliminate crude option parsingLibravatar Alexandr Miloslavskiy1-0/+5
Eliminate crude option parsing and rely on real parsing instead, because 1) Crude parsing is crude, for example it's not capable of handling things like `git stash -m Message` 2) Adding options in two places is inconvenient and prone to bugs As a side result, the case of `git stash -m Message` gets fixed. Also give a good error message instead of just throwing usage at user. ---- Some review of what's been happening to this code: Before [1], `git-stash.sh` only verified that all args begin with `-` : # The default command is "push" if nothing but options are given seen_non_option= for opt do case "$opt" in --) break ;; -*) ;; *) seen_non_option=t; break ;; esac done Later, [1] introduced the duplicate code I'm now removing, also making the previous test more strict by white-listing options. ---- [1] Commit 40af1468 ("stash: convert `stash--helper.c` into `stash.c`" 2019-02-26) Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-01Merge branch 'tg/stash-refresh-index'Libravatar Junio C Hamano1-1/+6
Recent update to "git stash pop" made the command empty the index when run with the "--quiet" option, which has been corrected. * tg/stash-refresh-index: stash: make sure we have a valid index before writing it
2019-11-14stash: make sure we have a valid index before writing itLibravatar Thomas Gummerer1-1/+6
In 'do_apply_stash()' we refresh the index in the end. Since 34933d0eff ("stash: make sure to write refreshed cache", 2019-09-11), we also write that refreshed index when --quiet is given to 'git stash apply'. However if '--index' is not given to 'git stash apply', we also discard the index in the else clause just before. We need to do so because we use an external 'git update-index --add --stdin', which leads to an out of date in-core index. Later we call 'refresh_and_write_cache', which now leads to writing the discarded index, which means we essentially write an empty index file. This is obviously not correct, or the behaviour the user wanted. We should not modify the users index without being asked to do so. Make sure to re-read the index after discarding the current in-core index, to avoid dealing with outdated information. Instead we could also drop the 'discard_cache()' + 'read_cache()', however that would make it easy to fall into the same trap as 34933d0eff did, so it's better to avoid that. We can also drop the 'refresh_and_write_cache' completely in the quiet case. Previously in legacy stash we relied on 'git status' to refresh the index after calling 'git read-tree' when '--index' was passed to 'git apply'. However the 'reset_tree()' call that replaced 'git read-tree' always passes options that are equivalent to '-m', making the refresh of the index unnecessary. Reported-by: Grzegorz Rajchman <rayman17@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Merge branch 'js/update-index-ignore-removal-for-skip-worktree'Libravatar Junio C Hamano1-0/+11
"git stash save" in a working tree that is sparsely checked out mistakenly removed paths that are outside the area of interest. * js/update-index-ignore-removal-for-skip-worktree: stash: handle staged changes in skip-worktree files correctly update-index: optionally leave skip-worktree entries alone
2019-11-02stash: handle staged changes in skip-worktree files correctlyLibravatar Johannes Schindelin1-0/+11
When calling `git stash` while changes were staged for files that are marked with the `skip-worktree` bit (e.g. files that are excluded in a sparse checkout), the files are recorded as _deleted_ instead. The reason is that `git stash` tries to construct the tree reflecting the worktree essentially by copying the index to a temporary one and then updating the files from the worktree. Crucially, it calls `git diff-index` to update also those files that are in the HEAD but have been unstaged in the index. However, when the temporary index is updated via `git update-index --add --remove`, skip-worktree entries mark the files as deleted by mistake. Let's use the newly-introduced `--ignore-skip-worktree-entries` option of `git update-index` to prevent exactly this from happening. Note that the regression test case deliberately avoids replicating the scenario described above and instead tries to recreate just the symptom. Reported by Dan Thompson. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07Merge branch 'tg/stash-refresh-index'Libravatar Junio C Hamano1-0/+16
"git stash" learned to write refreshed index back to disk. * tg/stash-refresh-index: stash: make sure to write refreshed cache merge: use refresh_and_write_cache factor out refresh_and_write_cache function
2019-09-20stash: make sure to write refreshed cacheLibravatar Thomas Gummerer1-0/+16
When converting stash into C, calls to 'git update-index --refresh' were replaced with the 'refresh_cache()' function. That is fine as long as the index is only needed in-core, and not re-read from disk. However in many cases we do actually need the refreshed index to be written to disk, for example 'merge_recursive_generic()' discards the in-core index before re-reading it from disk, and in the case of 'apply --quiet', the 'refresh_cache()' we currently have is pointless without writing the index to disk. Always write the index after refreshing it to ensure there are no regressions in this compared to the scripted stash. In the future we can consider avoiding the write where possible after making sure none of the subsequent calls actually need the refreshed cache, and it is not expected to be refreshed after stash exits or it is written somewhere else already. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-26t3903: abstract away SHA-1-specific constantsLibravatar brian m. carlson1-10/+22
Abstract away the SHA-1-specific constants by sanitizing diff output to remove the index lines, since it's clear from the assertions in question that we are not interested in the specific object IDs. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-25Merge branch 'tg/stash-keep-index-with-removed-paths'Libravatar Junio C Hamano1-0/+7
"git stash --keep-index" did not work correctly on paths that have been removed, which has been fixed. * tg/stash-keep-index-with-removed-paths: stash: fix handling removed files with --keep-index
2019-07-16stash: fix handling removed files with --keep-indexLibravatar Thomas Gummerer1-0/+7
git stash push --keep-index is supposed to keep all changes that have been added to the index, both in the index and on disk. Currently this doesn't behave correctly when a file is removed from the index. Instead of keeping it deleted on disk, --keep-index currently restores the file. Fix that behaviour by using 'git checkout' in no-overlay mode which can faithfully restore the index and working tree. This also simplifies the code. Note that this will overwrite untracked files if the untracked file has the same name as a file that has been deleted in the index. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-19stash: fix show referencing stash indexLibravatar Thomas Gummerer1-0/+18
In the conversion of 'stash show' to C in dc7bd382b1 ("stash: convert show to builtin", 2019-02-25), 'git stash show <n>', where n is the index of a stash got broken, if n is not a file or a valid revision by itself. 'stash show' accepts any flag 'git diff' accepts for changing the output format. Internally we use 'setup_revisions()' to parse these command line flags. Currently we pass the whole argv through to 'setup_revisions()', which includes the stash index. As the stash index is not a valid revision or a file in the working tree in most cases however, this 'setup_revisions()' call (and thus the whole command) ends up failing if we use this form of 'git stash show'. Instead of passing the whole argv to 'setup_revisions()', only pass the flags (and the command name) through, while excluding the stash reference. The stash reference is parsed (and validated) in 'get_stash_info()' already. This separate parsing also means that we currently do produce the correct output if the command succeeds. Reported-by: Mike Hommey <mh@glandium.org> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-21stash: setup default diff output format if necessaryLibravatar Thomas Gummerer1-0/+18
In the scripted 'git stash show' when no arguments are passed, we just pass '--stat' to 'git diff'. When any argument is passed to 'stash show', we no longer pass '--stat' to 'git diff', and pass whatever flags are passed directly through to 'git diff'. By default 'git diff' shows the patch output. So when a user uses 'git stash show --patience', they would be shown the diff as expected, using the patience algorithm. '--patience' in this case only changes the diff algorithm, but does not cause 'git diff' to show the diff by itself. The diff is shown because that's the default behaviour of 'git diff'. In the C version of 'git stash show', we try to emulate that behaviour using the internal diff API. However we forgot to set up the default output format, in case it wasn't set by any of the flags that were passed through. So 'git stash show --patience' in the builtin version of stash would be completely silent, while it would show the diff in the scripted version. The same thing would happen for other flags that only affect the way a patch is displayed, rather than switching to a different output format than the default one. Fix this by setting up the default output format for 'git diff'. Reported-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07stash: make push -q quietLibravatar Paul-Sebastian Ungureanu1-0/+23
There is a change in behaviour with this commit. When there was no initial commit, the shell version of stash would still display a message. This commit makes `push` to not display any message if `--quiet` or `-q` is specified. Add tests for `--quiet`. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07stash: rename test cases to be more descriptiveLibravatar Paul-Sebastian Ungureanu1-7/+7
Rename some test cases' labels to be more descriptive and under 80 characters per line. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07t3903: add test for --intent-to-add fileLibravatar Matthew Kraai1-0/+8
Add a test showing the 'git stash' behaviour with a file that has been added with 'git add --intent-to-add'. Stash fails to stash the file, so the purpose of this test is mainly to make sure git doesn't crash, but exits normally in this situation. This is in preparation for converting stash into a builtin. [tg: pulled the test out into a separate commit] Signed-off-by: Matthew Kraai <mkraai@its.jnj.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07t3903: modernize styleLibravatar Paul-Sebastian Ungureanu1-59/+61
Remove whitespaces after redirection operators and wrap long lines. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07stash: improve option parsing test coverageLibravatar Joel Teichroeb1-0/+35
In preparation for converting the stash command incrementally to a builtin command, this patch improves test coverage of the option parsing. Both for having too many parameters, or too few. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07ident: don't require calling prepare_fallback_ident firstLibravatar Thomas Gummerer1-0/+6
In fd5a58477c ("ident: add the ability to provide a "fallback identity"", 2019-02-25) I made it a requirement to call prepare_fallback_ident as the first function in the ident API. However in stash we didn't actually end up following that. This leads to a BUG if user.email and user.name are set. It was not caught in the test suite because we only rely on environment variables for setting the user name and email instead of the config. Instead of making it a bug to call other functions in the ident API first, just return silently if the identity of a user was already set up. Reported-by: Denton Liu <liu.denton@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19stash: tolerate missing user identityLibravatar Slavica Djukic1-0/+28
The "git stash" command insists on having a usable user identity to the same degree as the "git commit-tree" and "git commit" commands do, because it uses the same codepath that creates commit objects as these commands. It is not strictly necesary to do so. Check if we will barf before creating commit objects and then supply fake identity to please the machinery that creates commits. Add test to document that stash executes correctly both with and without valid ident. This is not that much of usability improvement, as the users who run "git stash" would eventually want to record their changes that are temporarily stored in the stashes in a more permanent history by committing, and they must do "git config user.{name,email}" at that point anyway, so arguably this change is only delaying a step that is necessary to work in the repository. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Slavica Djukic <slawica92@hotmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07t/*: fix ordering of expected/observed argumentsLibravatar Matthew DeVore1-4/+4
Fix various places where the ordering was obviously wrong, meaning it was easy to find with grep. Signed-off-by: Matthew DeVore <matvore@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22t3903-stash: don't try to grep non-existing fileLibravatar SZEDER Gábor1-1/+1
The test 'store updates stash ref and reflog' in 't3903-stash.sh' creates a stash from a new file, runs 'git reset --hard' to throw away any modifications to the work tree, and then runs '! grep' to ensure that the staged contents are gone. Since the file didn't exist before, it shouldn't exist after 'git reset' either. Consequently, this 'grep' doesn't fail as expected, because it can't find the staged content, but it fails because it can't open the file. Tighten this check by using 'test_path_is_missing' instead, thereby avoiding an unexpected error from 'grep' as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-23t: make many tests depend less on the refs being filesLibravatar David Turner1-1/+1
Many tests are very focused on the file system representation of the loose and packed refs code. As there are plans to implement other ref storage systems, let's migrate these tests to a form that test the intent of the refs storage system instead of it internals. This will make clear to readers that these tests do not depend on which ref backend is used. The internals of the loose refs backend are still tested in t1400-update-ref.sh, whereas the tests changed in this patch focus on testing other aspects. This patch just takes care of many low hanging fruits. It does not try to completely solves the issue. Helped-by: Stefan Beller <sbeller@google.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>