summaryrefslogtreecommitdiff
path: root/git-stash.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-07-01git stash: avoid data loss when "git stash save" kills a directoryLibravatar Petr Baudis1-0/+12
"stash save" is about saving the local change to the working tree, but also about restoring the state of the last commit to the working tree. When a local change is to turn a non-directory to a directory, in order to restore the non-directory, everything in the directory needs to be removed. Which is fine when running "git stash save --include-untracked", but without that option, untracked, newly created files in the directory will have to be discarded, if the state you are restoring to has a non-directory at the same path as the directory. Introduce a safety valve to fail the operation in such case, using the "ls-files --killed" which was designed for this exact purpose. The "stash save" is stopped when untracked files need to be discarded because their leading path ceased to be a directory, and the user is required to pass --force to really have the data removed. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17stash: introduce 'git stash store'Libravatar Ramkumar Ramachandra1-6/+41
save_stash() contains the logic for doing two potentially independent operations; the first is preparing the stash merge commit, and the second is updating the stash ref/ reflog accordingly. While the first operation is abstracted out into a create_stash() for callers to access via 'git stash create', the second one is not. Fix this by factoring out the logic for storing the stash into a store_stash() that callers can access via 'git stash store'. Like create, store is not intended for end user interactive use, but for callers in other scripts. We can simplify the logic in the rebase.autostash feature using this new subcommand. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17stash: simplify option parser for createLibravatar Ramkumar Ramachandra1-4/+1
The option parser for create unnecessarily checks "$1" inside a case statement that matches "$1" in the first place. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'ph/stash-rerere'Libravatar Junio C Hamano1-0/+1
"git stash" internally used "git merge-recursive" backend, which did not trigger "rerere" upon conflicts unlike other mergy operations. * ph/stash-rerere: stash: invoke rerere in case of conflict test: git-stash conflict sets up rerere
2012-08-17stash: invoke rerere in case of conflictLibravatar Phil Hord1-0/+1
"stash apply" directly calls a backend merge function which does not automatically invoke rerere. This confuses mergetool when leftover rerere state is left behind from previous merges. Invoke rerere explicitly when we encounter a conflict during stash apply. This turns the test introduced by the previous commit to succeed. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-14stash: use eval_gettextln correctlyLibravatar Ross Lagerwall1-2/+2
Otherwise, passing an invalid option, git stash -v, gave: git-stash: line 204: $'error: unknown option for \'stash save\': $option\n To provide a message, use git stash save -- \'$option\'': command not found Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-01stash: Don't fail if work dir contains file named 'HEAD'Libravatar Jonathon Mah1-3/+4
When performing a plain "git stash" (without --patch), git-diff would fail with "fatal: ambiguous argument 'HEAD': both revision and filename". The output was piped into git-update-index, masking the failed exit status. The output is now sent to a temporary file (which is cleaned up by existing code), and the exit status is checked. The "HEAD" arg to the git-diff invocation has been disambiguated too, of course. In patch mode, "git stash -p" would fail harmlessly, leaving the working dir untouched. Interactive adding is fine, but the resulting tree was diffed with an ambiguous 'HEAD' argument. Use >foo (no space) when redirecting output. In t3904, checks and operations on each file are in the order they'll appear when interactively staging. In t3905, fix a bug in "stash save --include-untracked -q is quiet": The redirected stdout file was considered untracked, and so was removed from the working directory. Use test path helper functions where appropriate. Signed-off-by: Jonathon Mah <me@JonathonMah.com> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'bc/unstash-clean-crufts'Libravatar Junio C Hamano1-2/+2
* bc/unstash-clean-crufts: git-stash: remove untracked/ignored directories when stashed t/t3905: add missing '&&' linkage git-stash.sh: fix typo in error message t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
2011-08-27git-stash: remove untracked/ignored directories when stashedLibravatar Brandon Casey1-1/+1
The two new stash options --include-untracked and --all do not remove the untracked and/or ignored files that are stashed if those files reside in a subdirectory. e.g. the following sequence fails: mkdir untracked && echo hello >untracked/file.txt && git stash --include-untracked && test ! -f untracked/file.txt Within the git-stash script, git-clean is used to remove the untracked/ignored files, but since the -d option was not supplied, it does not remove directories. So, add -d to the git-clean arguments, and update the tests to test this functionality. Reported-by: Hilco Wijbenga <hilco.wijbenga@gmail.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-27git-stash.sh: fix typo in error messageLibravatar Brandon Casey1-1/+1
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08stash: take advantage of eval_gettextlnLibravatar Jon Seymour1-6/+3
Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-22Merge branch 'dc/stash-con-untracked'Libravatar Junio C Hamano1-5/+65
* dc/stash-con-untracked: stash: Add --include-untracked option to stash and remove all untracked files Conflicts: git-stash.sh
2011-06-26stash: Add --include-untracked option to stash and remove all untracked filesLibravatar David Caldwell1-4/+64
The --include-untracked option acts like the normal "git stash save" but also adds all untracked files in the working directory to the stash and then calls "git clean --force --quiet" to restore the working directory to a pristine state. This is useful for projects that need to run release scripts. With this option, the release scripts can be from the main working directory so one does not have to maintain a "clean" directory in parallel just for releasing. Basically the work-flow becomes: $ git tag release-1.0 $ git stash --include-untracked $ make release $ git clean -f $ git stash pop "git stash" alone is not enough in this case--it leaves untracked files lying around that might mess up a release process that expects everything to be very clean or might let a release succeed that should actually fail (due to a new source file being created that hasn't been committed yet). Signed-off-by: David Caldwell <david@porkrind.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash drop_stash say/die messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Gettextize the say/die eval_gettext messages in the drop_stash function. Since making these translatable would result in a long line I've wrapped this into two lines. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash "unknown option" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+13
Gettextize the "unknown option for 'stash save'" message that's shown on: $ git stash save --blah-blah error: unknown option for 'stash save': --blah-blah To provide a message, use git stash save -- '--blah-blah' Usage: git stash list [<options>] In a translation the second line should be aligned with the first one. I've added a TRANSLATORS comment to indicate this. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + eval_gettext $1 messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+4
Gettextize a messages that used the $1 variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + eval_gettext $* messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+8
Gettextize messages that used the $* variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + eval_gettext messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash die + gettext messagesLibravatar Ævar Arnfjörð Bjarmason1-18/+18
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash say + gettext messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash echo + gettext messageLibravatar Ævar Arnfjörð Bjarmason1-1/+4
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-stash add git-sh-i18nLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-04Merge branch 'jk/maint-stash-oob' into maintLibravatar Junio C Hamano1-11/+1
* jk/maint-stash-oob: stash: fix false positive in the invalid ref test. stash: fix accidental apply of non-existent stashes Conflicts: t/t3903-stash.sh
2011-05-04Merge branch 'dm/stash-k-i-p' into maintLibravatar Junio C Hamano1-4/+5
* dm/stash-k-i-p: stash: ensure --no-keep-index and --patch can be used in any order stash: add two more tests for --no-keep-index
2011-04-27Merge branch 'dm/stash-k-i-p'Libravatar Junio C Hamano1-4/+5
* dm/stash-k-i-p: stash: ensure --no-keep-index and --patch can be used in any order stash: add two more tests for --no-keep-index
2011-04-27Merge branch 'jk/maint-stash-oob'Libravatar Junio C Hamano1-11/+1
* jk/maint-stash-oob: stash: fix false positive in the invalid ref test. stash: fix accidental apply of non-existent stashes Conflicts: t/t3903-stash.sh
2011-04-07stash: ensure --no-keep-index and --patch can be used in any orderLibravatar Dan McGee1-4/+5
Don't assume one comes after the other on the command line. Use a three-state variable to track and check its value accordingly. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06stash: drop dirty worktree check on applyLibravatar Jeff King1-3/+1
Before we apply a stash, we make sure there are no changes in the worktree that are not in the index. This check dates back to the original git-stash.sh, and is presumably intended to prevent changes in the working tree from being accidentally lost during the merge. However, this check has two problems: 1. It is overly restrictive. If my stash changes only file "foo", but "bar" is dirty in the working tree, it will prevent us from applying the stash. 2. It is redundant. We don't touch the working tree at all until we actually call merge-recursive. But it has its own (much more accurate) checks to avoid losing working tree data, and will abort the merge with a nicer message telling us which paths were problems. So we can simply drop the check entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05stash: fix accidental apply of non-existent stashesLibravatar Jeff King1-11/+1
Once upon a time, "git rev-parse ref@{9999999}" did not generate an error. Therefore when we got an invalid stash reference in "stash apply", we could end up not noticing until quite late. Commit b0f0ecd (detached-stash: work around git rev-parse failure to detect bad log refs, 2010-08-21) handled this by checking for the "Log for stash has only %d entries" warning on stderr when we validated the ref. A few days later, e6eedc3 (rev-parse: exit with non-zero status if ref@{n} is not valid., 2010-08-24) fixed the original issue. That made the extra stderr test superfluous, but also introduced a new bug. Now the early call to: git rev-parse --symbolic "$@" fails, but we don't notice the exit code. Worse, its empty output means we think the user didn't provide us a ref, and we try to apply stash@{0}. This patch checks the rev-parse exit code and fails early in the revision parsing process. We can also get rid of the stderr test; as a bonus, this means that "stash apply" can now run under GIT_TRACE=1 properly. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-23Merge branch 'pk/stash-apply-status-relative'Libravatar Junio C Hamano1-1/+2
* pk/stash-apply-status-relative: Add test: git stash shows status relative to current dir git stash: show status relative to current directory
2011-03-17stash: copy the index using --index-output instead of cp -pLibravatar Johannes Sixt1-6/+5
'git stash create' must operate with a temporary index. For this purpose, it used 'cp -p' to create a copy. -p is needed to preserve the timestamp of the index file. Now Jakob Pfender reported a certain combination of a Linux NFS client, OpenBSD NFS server, and cp implementation where this operation failed. Luckily, the first operation in git-stash after copying the index is to call 'git read-tree'. Therefore, use --index-output instead of 'cp -p' to write the copy of the index. --index-output requires that the specified file is on the same volume as the source index, so that the lock file can be rename()d. For this reason, the name of the temporary index is constructed in a way different from the other temporary files. The code path of 'stash -p' also needs a temporary index, but we do not use the new name because it does not depend on the same precondition as --index-output. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-17stash: fix incorrect quoting in cleanup of temporary filesLibravatar Johannes Sixt1-1/+1
The * was inside the quotes, so that the pattern was never expanded and the temporary files were never removed. As a consequence, 'stash -p' left a .git-stash-*-patch file in $GIT_DIR. Other code paths did not leave files behind because they removed the temporary file themselves, at least in non-error paths. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-14git stash: show status relative to current directoryLibravatar Piotr Krukowiecki1-1/+2
git status shows modified paths relative to current directory, so it's possible to copy&paste them directly, even if you're in a subdirectory. But "git stash apply" always shows status from root of git repository. This is misleading because you can't use the paths without modifications. This is caused by changing directory to root of repository at the beginning of git stash. This patch makes git stash show status relative to current directory. Instead of removing the "cd to toplevel", which would affect whole script and might have other side-effects, the fix is to change directory temporarily back to original dir just before displaying status. Signed-off-by: Piotr Krukowiecki <piotr.krukowiecki@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13shell portability: no "export VAR=VAL"Libravatar Junio C Hamano1-1/+1
It is more portable to say "VAR=VAL && export VAR" instead. Noticed by Ævar. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29stash: simplify parsing fixesLibravatar Jon Seymour1-21/+7
This patch simplifies Brian's fix for the recent regression by: * eliminating the extra loop * eliminating use of git rev-parse for parsing flags * making use of the for opt idiom for the retained loop * eliminating the redundant -- case The patch has been tested with the tests in current maint. Signed-off-by: Jon Seymour <jon.seymour@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-3/+3
"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-26git-stash: fix flag parsingLibravatar Brian Gernhardt1-4/+11
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>
2010-08-21detached-stash: simplify git stash showLibravatar Jon Seymour1-12/+2
This commit refactors git stash show to make use of the assert_stash_like function. git show now dies if the presented argument is non-stash-like. Previous behaviour was to tolerate commits that were not even stash-like. Previously, git stash show would accept stash-like arguments, but only if there was a stash on the stack. Now, git stash accepts stash-like arguments always and only fails if no stash-like argument is specified and there is no stash stack. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21detached-stash: simplify git stash branchLibravatar Jon Seymour1-10/+7
This patch teaches git stash branch to tolerate stash-like arguments. In particular, a stash is only required if an argument isn't specified and the stash is only dropped if a stash entry reference was specified or implied. The implementation has been simplified by taking advantage of assert_stash_like() and the variables established by parse_flags_and_rev(). Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21detached-stash: refactor git stash pop implementationLibravatar Jon Seymour1-4/+8
git stash pop is abstracted into its own implementation function - pop_stash. The behaviour is changed so that git stash pop fails early if the the specified stash reference does not exist or does not refer to an extant entry in the reflog of the reference stash. This fixes the case where the apply succeeds, but the drop fails. Previously this caused caused git stash pop to exit with a non-zero exit code and a dirty tree. Now, git stash pop fails with a non-zero exit code, but the working tree is not modified. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21detached-stash: simplify stash_dropLibravatar Jon Seymour1-28/+3
Previously, git stash drop would fail noisily while executing git reflog delete if the specified revision was not a stash reference. Now, git stash drop fails with an error message which more precisely indicates the reason for failure. Furthermore, git stash drop will now fail with a non-zero status code if stash@{n} specifies a stash log entry that does not actually exist. This change in behaviour is achieved by delegating argument parsing to the common parse_flags_and_rev() function (via a call to assert_stash_ref). Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21detached-stash: simplify stash_applyLibravatar Jon Seymour1-35/+3
The implementation of stash_apply() is simplified to take advantage of the common parsing function parse_flags_and_rev(). Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21detached-stash: work around git rev-parse failure to detect bad log refsLibravatar Jon Seymour1-0/+9
This commit is required because git rev-parse in 1.7.2 does not correctly indicate invalid log references using a non-zero status code. We use a proxy for the condition (non-empty error output) as a substitute. This commit can be reverted when, and if, rev-parse is fixed to indicate invalid log references with a status code. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21detached-stash: introduce parse_flags_and_revs functionLibravatar Jon Seymour1-0/+124
Introduce parse_flags_and_revs. This function requires that there is at most one stash-like revision parameter and zero or more flags. It knows how to parse -q,--quiet and --index flags, but leaves other flags parsed. Specified revisions are checked to see that they are at least stash-like (meaning: they look like something created by git stash save or git stash create). If this is so, then IS_STASH_LIKE is initialized to a non-empty value. If the specified revision also looks like a stash log entry reference, then IS_STASH_REF is initialized to a non-empty value. References of the form ref@{spec} are required to precisely identify an individual commit. If no reference is specified, stash@{0} is assumed. Once the specified reference is validated to be at least stash_like an ensemble of derived variables, (w_commit, w_tree, b_commit, etc) is initialized with a single call to git rev-parse. Repeated calls to parse_flags_and_rev() avoid repeated calls to git rev-parse if the specified arguments have already been parsed. Subsequent patches in the series modify the existing git stash subcommands to make use of these functions as appropriate. An ensemble of supporting functions that make use of the state established by parse_flags_and_rev(). These are described below: The ancillary functions are: is_stash_like(): which can be used to test whether a specified commit looks like a commit created with git stash save or git stash create. assert_stash_like(): which can be used by commands that misbehave unless their arguments stash-like. is_stash_ref(): which checks whether an argument is valid stash reference(e.g. is of the form ['refs/']stash['@{'something'}]) assert_stash_ref(): which can be used by commands that misbehave unless their arguments are both stash-like and refer to valid stash entries. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21Merge branch 'cb/maint-stash-orphaned-file'Libravatar Junio C Hamano1-1/+1
* cb/maint-stash-orphaned-file: stash tests: stash can lose data in a file removed from the index stash: Don't overwrite files that have gone from the index
2010-05-08Merge branch 'sd/log-decorate'Libravatar Junio C Hamano1-1/+1
* sd/log-decorate: log.decorate: only ignore it under "log --pretty=raw" script with rev-list instead of log log --pretty/--oneline: ignore log.decorate log.decorate: usability fixes Add `log.decorate' configuration variable. git_config_maybe_bool() Conflicts: builtin/log.c
2010-04-18stash: Don't overwrite files that have gone from the indexLibravatar Charles Bailey1-1/+1
The use of git add -u in create_stash isn't always complete. In particular, if a file has been removed from the index but changed in the work tree it will not be added to the stash's saved work tree tree object. When stash then resets the work tree to match HEAD, any changes will be lost. To be complete, any work tree file which differs from HEAD needs to be saved, regardless of whether it still appears in the index or not. This is achieved with a combination of a diff against HEAD and a call to update-index with an explicit list of paths that have changed. Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-08script with rev-list instead of logLibravatar Jeff King1-1/+1
Because log.decorate now shows decorations for --pretty=oneline, we must explicitly turn it off when scripting. Otherwise, users with log.decorate set will get cruft like: $ git stash Saved working directory and index state WIP on master: 2c1f7f5 (HEAD, master) commit subject Instead of adding --no-decorate to the log command line, let's just use the rev-list plumbing interface instead, which does the right thing. git-submodule has a similar call. Since it just counts the commit lines, nothing is broken, but let's switch it, too, for the sake of consistency and cleanliness. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-16Improve error messages from 'git stash show'Libravatar Gustaf Hendeby1-2/+6
The previous error message "fatal: Needed a single revision" is not very informative. Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06stash: suggest the correct command line for unknown options.Libravatar Matthieu Moy1-0/+1
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>