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?

  • Does git commit --amend include the files that were in the last commit?
  • How to force the update of a gem with bundler?
  • git: obtain the benefits of `git rebase --interactive` for cherry picks
  • running cooja in contiki with cmd “ant run”
  • Running Git through Cygwin from Windows
  • gitignore: Understanding “hello/” vs. “hello/*”
  • How to merge branches in Git by “hunk”
  • Is there any way to force a git add ignoring line ending problems?
  • svn (with git frontend) branch merging with different directory structure
  • Migrate SVN-Repositories into Gitblit
  • Unable to connect to on push and pull
  • Split a Subversion Repository Project to Two Git Repositories
  • 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.