summaryrefslogtreecommitdiff
path: root/Documentation/git-stash.txt
AgeCommit message (Collapse)AuthorFilesLines
2021-02-11git-stash.txt: be explicit about subcommand optionsLibravatar Denton Liu1-4/+4
Currently, the options for the `list` and `show` subcommands are just listed as `<options>`. This seems to imply, from a cursory glance at the summary, that they take the stash options listed below. However, reading more carefully, we see that they take log options and diff options respectively. Make it more obvious that they take log and diff options by explicitly stating this in the subcommand summary. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19stash push: support the --pathspec-from-file optionLibravatar Alexandr Miloslavskiy1-1/+19
Decisions taken for simplicity: 1) For now, `--pathspec-from-file` is declared incompatible with `--patch`, even when <file> is not `-`. Such use case is not really expected. 2) It is not allowed to pass pathspec in both args and file. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: synchronize <pathspec> descriptionLibravatar Alexandr Miloslavskiy1-2/+4
This patch continues the effort that is already applied to `git commit`, `git reset`, `git checkout` etc. 1) Added reference to 'linkgit:gitglossary[7]'. 2) Fixed mentions of incorrectly plural "pathspecs". Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: document more optionsLibravatar Alexandr Miloslavskiy1-0/+12
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: split options from description (2)Libravatar Alexandr Miloslavskiy1-35/+57
Together with the previous patch, this brings docs for `git stash` to the common layout used for most other commands (see for example docs for `git add`, `git commit`, `git checkout`, `git reset`) where all options are documented in a separate list. After some thinking and having a look at docs for `git svn` and `git `submodule`, I have arrived at following conclusions: * Options should be described in a list rather then text to facilitate lookup for user. * Single list is better then multiple lists because it avoids copy&pasting descriptions between subcommands (or, without copy&pasting, user will have to look up missing options in other subcommands). * As a consequence, commands section should only give brief info and list possible options. Since options have good enough names, user will only need to look up the "interesting" options. * Every option should list which subcommands support it. I have decided to use alphabetical sorting in the list of options to facilitate lookup for user. There is some text editing done to make old descriptions better fit into the list-style format. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: split options from description (1)Libravatar Alexandr Miloslavskiy1-33/+35
This patch moves blocks of text as-is to make it easier to review the next patch. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-11doc(stash): clarify the description of `save`Libravatar Johannes Schindelin1-2/+3
The original phrasing of this paragraph made at least one person stumble over the word "from" (thinking that it was a typo and "from" was intended), and other readers chimed in, agreeing that it was confusing: https://public-inbox.org/git/0102016b8d597569-c1f6cfdc-cb45-4428-8737-cb1bc30655d8-000000@eu-west-1.amazonses.com/#t Let's rewrite that paragraph for clarity. Inspired-by-a-patch-by: Catalin Criste <cris_linu_w@yahoo.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-4/+5
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-04-02doc: promote "git switch"Libravatar Nguyễn Thái Ngọc Duy1-4/+5
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07stash: mention options in `show` synopsisLibravatar Paul-Sebastian Ungureanu1-2/+2
Mention in the documentation, that `show` accepts any option known to `git diff`. 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>
2018-03-27git-stash.txt: remove extra square bracketLibravatar Thomas Gummerer1-1/+1
In 1ada5020b3 ("stash: use stash_push for no verb form", 2017-02-28), when the pathspec argument was introduced in 'git stash', that was also documented. However I forgot to remove an extra square bracket after the '--message' argument, even though the square bracket should have been after the pathspec argument (where it was also added). Remove the extra square bracket after the '--message' argument, to show that the pathspec argument should be used with the 'push' verb. While the pathspec argument can be used without the push verb, that's a special case described later in the man page, and removing the first extra square bracket instead of the second one makes the synopis easier to understand. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22doc: prefer 'stash push' over 'stash save'Libravatar Phil Hord1-2/+2
Although `git stash save` was deprecated recently, some parts of the documentation still refer to it instead of `push`. Signed-off-by: Phil Hord <phil.hord@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-27stash: mark "git stash save" deprecated in the man pageLibravatar Thomas Gummerer1-3/+6
'git stash push' fixes a historical wart in the interface of 'git stash save'. As 'git stash push' has all functionality of 'git stash save', with a nicer, more consistent user interface deprecate 'git stash save'. To do this, remove it from the synopsis of the man page, and move it to a separate section, stating that it is deprecated. Helped-by: Robert P. J. Day <rpjday@crashcourse.ca> 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>
2017-10-27stash: replace "git stash save" with "git stash push" in the documentationLibravatar Thomas Gummerer1-6/+6
"git stash push" is the newer interface for creating a stash. While we are still keeping "git stash save" around for the time being, it's better to point new users of "git stash" to the more modern (and more feature rich) interface, instead of teaching them the older version that we might want to phase out in the future. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18stash: update documentation to use 'stash entry'Libravatar Liam Beguin1-29/+31
Most of the time, a 'stash entry' is called a 'stash'. Lets try to make this more consistent and use 'stash entry' instead. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28stash: allow pathspecs in the no verb formLibravatar Thomas Gummerer1-4/+7
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-4/+4
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-1/+8
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: introduce push verbLibravatar Thomas Gummerer1-0/+3
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-02-13Documentation/stash: remove mention of git reset --hardLibravatar Thomas Gummerer1-2/+3
Don't mention git reset --hard in the documentation for git stash save. It's an implementation detail that doesn't matter to the end user and thus shouldn't be exposed to them. In addition it's not quite true for git stash -p, and will not be true when a filename argument to limit the stash to a few files is introduced. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26stash: allow stashes to be referenced by index onlyLibravatar Aaron M Watson1-1/+2
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-08-31stash: allow "stash show" diff output configurableLibravatar Namhyung Kim1-0/+2
Some users might want to see diff (patch) output always rather than diffstat when [s]he runs 'git stash show'. Although this can be done with adding -p option, users are too lazy to type extra three keys. Add two variables that control to show diffstat and patch output respectively. The stash.showStat is for diffstat and default is true. The stat.showPatch is for the patch output and default is false. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24stash doc: mention short form -k in save descriptionLibravatar John Marshall1-1/+1
Document --keep-index's short form -k in both main synopsis and the save synopsis in the Options section. Signed-off-by: John Marshall <jm18@sanger.ac.uk> 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-10/+2
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-2/+10
"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-0/+7
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 doc: document short form -p in synopsisLibravatar Ramkumar Ramachandra1-1/+1
'git stash save' can take -p, the short form of --patch, as an option. Document this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17stash doc: add a warning about using createLibravatar Ramkumar Ramachandra1-1/+3
Add a note saying that the user probably wants "save" in the create description. While at it, document that it can optionally take a message in the synopsis. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-10Documentation/git-stash.txt: add a missing verbLibravatar Sébastien Loriot1-1/+1
Signed-off-by: Sébastien Loriot <sloriot.ml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-9/+9
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-26stash: Add --include-untracked option to stash and remove all untracked filesLibravatar David Caldwell1-2/+8
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-05git-stash.txt: better docs for '--patch'Libravatar Valentin Haenel1-4/+5
Describe '-p' as a short form of '--patch' in synopsis and options. Also refer the reader to the patch mode description of git-add documentation. Helped-by: Jeff King <peff@peff.net> Mentored-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-4/+0
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2010-08-21detached-stash: update DocumentationLibravatar Jon Seymour1-5/+11
Update the documentation to indicate that git stash branch only attempts to drop the specified stash if it looks like stash reference. Also changed the synopsis to more clearly indicate which commands require a stash entry reference as opposed to merely a stash-like commit. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17docs: don't talk about $GIT_DIR/refs/ everywhereLibravatar Jeff King1-1/+1
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we may also consult the packed refs mechanism. These days we tend to treat the "refs hierarchy" as more of an abstract namespace that happens to be represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at worst it can confuse users who then look in $GIT_DIR/refs and find that it is missing some of the refs they expected to see. This patch drops most uses of "$GIT_DIR/refs/*", changing them into just "refs/*", under the assumption that users can handle the concept of an abstract refs namespace. There are a few things to note: - most cases just dropped the $GIT_DIR/ portion. But for cases where that left _just_ the word "refs", I changed it to "refs/" to help indicate that it was a hierarchy. I didn't do the same for longer paths (e.g., "refs/heads" remained, instead of becoming "refs/heads/"). - in some cases, no change was made, as the text was explicitly about unpacked refs (e.g., the discussion in git-pack-refs). - In some cases it made sense instead to note the existence of packed refs (e.g., in check-ref-format and rev-parse). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-3/+3
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2010-01-10Documentation: format full commands in typewriter fontLibravatar Thomas Rast1-1/+1
Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2009-10-19stash list: drop the default limit of 10 stashesLibravatar Thomas Rast1-2/+1
'git stash list' had an undocumented limit of 10 stashes, unless other git-log arguments were specified. This surprised at least one user, but possibly served to cut the output below a screenful without using a pager. Since the last commit, 'git stash list' will fire up a pager according to the same rules as the 'git log' it calls, so we can drop the limit. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-13Merge branch 'maint-1.6.4' into maintLibravatar Junio C Hamano1-1/+2
* maint-1.6.4: git-stash documentation: mention default options for 'list'
2009-10-12git-stash documentation: mention default options for 'list'Libravatar Miklos Vajna1-1/+2
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07Merge branch 'tr/reset-checkout-patch'Libravatar Junio C Hamano1-5/+17
* tr/reset-checkout-patch: stash: simplify defaulting to "save" and reject unknown options Make test case number unique tests: disable interactive hunk selection tests if perl is not available DWIM 'git stash save -p' for 'git stash -p' Implement 'git stash save --patch' Implement 'git checkout --patch' Implement 'git reset --patch' builtin-add: refactor the meat of interactive_add() Add a small patch-mode testing library git-apply--interactive: Refactor patch mode code Make 'git stash -k' a short form for 'git stash save --keep-index'
2009-09-01stash: simplify defaulting to "save" and reject unknown optionsLibravatar Matthieu Moy1-4/+5
With the earlier DWIM patches, certain combination of options defaulted to the "save" command correctly while certain equally valid combination did not. For example, "git stash -k" were Ok but "git stash -q -k" did not work. This makes the logic of defaulting to "save" much simpler. If there are no non-flag arguments, it is clear that there is no command word, and we default to "save" subcommand. This rule prevents "git stash -q apply" from quietly creating a stash with "apply" as the message. This also teaches "git stash save" to reject an unknown option. This is to keep a mistyped "git stash save --quite" from creating a stash with a message "--quite", and this safety is more important with the new logic to default to "save" with any option-looking argument without an explicit comand word. [jc: this is based on Matthieu's 3-patch series, and a follow-up discussion, and he and Peff take all the credit; if I have introduced bugs while reworking, they are mine.] Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15DWIM 'git stash save -p' for 'git stash -p'Libravatar Thomas Rast1-1/+1
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15Merge branch 'js/stash-dwim' into tr/reset-checkout-patchLibravatar Junio C Hamano1-1/+2
* commit 'tr/reset-checkout-patch^^2': Make 'git stash -k' a short form for 'git stash save --keep-index'
2009-08-15Implement 'git stash save --patch'Libravatar Thomas Rast1-2/+12
This adds a hunk-based mode to git-stash. You can select hunks from the difference between HEAD and worktree, and git-stash will build a stash that reflects these changes. The index state of the stash is the same as your current index, and we also let --patch imply --keep-index. Note that because the selected hunks are rolled back from the worktree but not the index, the resulting state may appear somewhat confusing if you had also staged these changes. This is not entirely satisfactory, but due to the way stashes are applied, other solutions would require a change to the stash format. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09Document 'stash clear' recovery via unreachable commitsLibravatar Thomas Rast1-1/+16
Add an example to the stash documentation that shows how to quickly find candidate commits among the 'git fsck --unreachable' output. Unless you have merges of branch names containing WIP, or edit your merge messages to say WIP, there will be no false positives. Snippet written by Björn "doener" Steinbrink and me after zepolen_ asked on IRC. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-31Make 'git stash -k' a short form for 'git stash save --keep-index'Libravatar Johannes Schindelin1-1/+2
To save me from the carpal tunnel syndrome, make 'git stash' accept the short option '-k' instead of '--keep-index', and for even more convenience, let's DWIM when this developer forgot to type the 'save' command. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-18stash: teach quiet optionLibravatar Stephen Boyd1-7/+8
Teach stash pop, apply, save, and drop to be quiet when told. By using the quiet option (-q), these actions will be silent unless errors are encountered. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-09Documentation: mention 'git stash pop --index' option explicitlyLibravatar SZEDER Gábor1-8/+8
'git stash pop' supports the '--index' option since its initial implementation (bd56ff54, git-stash: add new 'pop' subcommand, 2008-02-22), but its documentation does not mention it explicitly. Moreover, both the usage shown by 'git stash -h' and the synopsis section in the man page imply that 'git stash pop' does not have an '--index' option. First, this patch corrects the usage and the synopsis section. Second, the patch moves the description of the '--index' option to the 'git stash pop' section in the documentation, and refers to it from the 'git stash apply' section. This way it follows the intentions of commit d1836637 (Documentation: teach stash/pop workflow instead of stash/apply, 2009-05-28), as all 'git stash pop'-related documentation will be in one place without references to 'git stash apply'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-30Documentation: teach stash/pop workflow instead of stash/applyLibravatar Thomas Rast1-14/+16
Recent discussion on the list showed some comments in favour of a stash/pop workflow: http://marc.info/?l=git&m=124234911423358&w=2 http://marc.info/?l=git&m=124235348327711&w=2 Change the stash documentation and examples to document pop in its own right (and apply in terms of pop), and use stash/pop in the examples. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>