Is it possible to search through Git Stash items?

So I’m learning about using Git Stash this week and figured out all of theses stashes have been accumulating on my system. I’ve misplaced some code and I now have a dozen stashes of code 0-11.

Is there a way that I can search through these stashes for a string value in the files within the stash to find the code I’m looking for?
Do I just have to go through and reapply each stash to search/look in them for the code I’m trying to find?

  • Git diff command showing entire file is modified instead of showing modified small part of code
  • Reference files from one repository to another
  • How do I clone my git repo of sublime-text-2 settings to another computer
  • configure Git to accept a particular self-signed server certificate for a particular https remote
  • What Git '--progress' flag is for and how to use it
  • Git push stuck at 99%
  • Listing all repositories served by git-daemon
  • How do I ignore file extensions in git regardless of case?
  • git submodule sync doesn't work
  • How to begin committing via git to bitbucket - Not seeing changes
  • Add all non-controlled files?
  • What should I do when I get “TortoiseMerge cannot be used without a base”?
  • 2 Solutions collect form web for “Is it possible to search through Git Stash items?”

    git stash show -p stash@{n} | grep "john cena" is the only option I think.

    Of course you can write your own script around that.

    The git grep command accepts a “tree” object:


    git grep [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
                  [-v | --invert-match] [-h|-H] [--full-name]
                  [-E | --extended-regexp] [-G | --basic-regexp]
                  [-P | --perl-regexp]
                  [-F | --fixed-strings] [-n | --line-number]
                  [-l | --files-with-matches] [-L | --files-without-match]
                  [(-O | --open-files-in-pager) [<pager>]]
                  [-z | --null]
                  [-c | --count] [--all-match] [-q | --quiet]
                  [--max-depth <depth>]
                  [--color[=<when>] | --no-color]
                  [--break] [--heading] [-p | --show-function]
                  [-A <post-context>] [-B <pre-context>] [-C <context>]
                  [-W | --function-context]
                  [--threads <num>]
                  [-f <file>] [-e] <pattern>
                  [--and|--or|--not|(|)|-e <pattern>...]
                  [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>...]
                  [--] [<pathspec>...]

    Now consider that a stash entry is a tree object synthesized from the
    contents of the work tree at the time you have called git stash
    with its two parents being the state at HEAD
    and the state in the index; to cite the manual:

    A stash is represented as a commit whose tree records
    the state of the working
    directory, and its first parent is the commit at HEAD
    when the stash was created.
    The tree of the second parent records the state of the index when the
    stash is made, and it is made a child of the HEAD commit.
    The ancestry graph looks like this:

                 /    /

    where H is the HEAD commit,
    I is a commit that records the state of the index,
    and W is a commit that records the state of the working tree.

    So you can have tree places to grep your stash entry for:

    • git grep [options] term stash@{n} would grep that W commit
      for the term, that is,
      it would grep the saved state of the working tree files.

    • To grep the state of the index of a stashed entry you need to refer
      to the second parent of W; this is done using the ^2 suffix:

       git grep [options] term stash@{n}^2
    • To grep the state of the stash entry’s baseline commit—the least
      interesting case—refer to its first parent:

       git grep [options] term stash@{n}^1

    The ^<n> notation is explained in the git help revisions manual:

    <rev>^, e.g. HEAD^, v1.5.1^0 A suffix ^ to a revision
    parameter means the first parent of that commit object. ^<n> means
    the <n>th parent (i.e. <rev>^ is equivalent to <rev>^1). As a
    special rule, <rev>^0 means the commit itself and is used when
    <rev> is the object name of a tag object that refers to a commit


    For the top stash entry, use

    • git grep whatever stash@{0} to grep what was the state of the
      working tree.
    • git grep whatever stash@{0}^2 to grep what was the state of the
    Git Baby is a git and github fan, let's start git clone.