Asked  7 Months ago    Answers:  5   Viewed   33 times

I have deleted a file or some code in a file sometime in the past. Can I grep in the content (not in the commit messages)?

A very poor solution is to grep the log:

git log -p | grep <pattern>

However, this doesn't return the commit hash straight away. I played around with git grep to no avail.

 Answers

77

To search for commit content (i.e., actual lines of source, as opposed to commit messages and the like), you need to do:

git grep <regexp> $(git rev-list --all)

git rev-list --all | xargs git grep <expression> will work if you run into an "Argument list too long" error.

If you want to limit the search to some subtree (for instance, "lib/util"), you will need to pass that to the rev-list subcommand and grep as well:

git grep <regexp> $(git rev-list --all -- lib/util) -- lib/util

This will grep through all your commit text for regexp.

The reason for passing the path in both commands is because rev-list will return the revisions list where all the changes to lib/util happened, but also you need to pass to grep so that it will only search in lib/util.

Just imagine the following scenario: grep might find the same <regexp> on other files which are contained in the same revision returned by rev-list (even if there was no change to that file on that revision).

Here are some other useful ways of searching your source:

Search working tree for text matching regular expression regexp:

git grep <regexp>

Search working tree for lines of text matching regular expression regexp1 or regexp2:

git grep -e <regexp1> [--or] -e <regexp2>

Search working tree for lines of text matching regular expression regexp1 and regexp2, reporting file paths only:

git grep -l -e <regexp1> --and -e <regexp2>

Search working tree for files that have lines of text matching regular expression regexp1 and lines of text matching regular expression regexp2:

git grep -l --all-match -e <regexp1> -e <regexp2>

Search working tree for changed lines of text matching pattern:

git diff --unified=0 | grep <pattern>

Search all revisions for text matching regular expression regexp:

git grep <regexp> $(git rev-list --all)

Search all revisions between rev1 and rev2 for text matching regular expression regexp:

git grep <regexp> $(git rev-list <rev1>..<rev2>)
Tuesday, June 1, 2021
 
edorian
answered 7 Months ago
17

If you do not know the exact path you may use

git log --all --full-history -- "**/thefile.*"

If you know the path the file was at, you can do this:

git log --all --full-history -- <path-to-file>

This should show a list of commits in all branches which touched that file. Then, you can find the version of the file you want, and display it with...

git show <SHA> -- <path-to-file>

Or restore it into your working copy with:

git checkout <SHA>^ -- <path-to-file>

Note the caret symbol (^), which gets the checkout prior to the one identified, because at the moment of <SHA> commit the file is deleted, we need to look at the previous commit to get the deleted file's contents

Friday, June 4, 2021
 
apokryfos
answered 6 Months ago
59
git checkout -m <filename>

This will remove it from the index, and revert back to a "conflicted" file that has all of the markers required to then do a merge.

From the git help checkout man page:

-m, --merge
    When switching branches, if you have local modifications to
    one or more files that are different between the current
    branch and the branch to which you are switching, the command
    refuses to switch branches in order to preserve your
    modifications in context. However, with this option, a
    three-way merge between the current branch, your working tree
    contents, and the new branch is done, and you will be on the
    new branch.

    When a merge conflict happens, the index entries for
    conflicting paths are left unmerged, and you need to resolve
    the conflicts and mark the resolved paths with git add (or git
    rm if the merge should result in deletion of the path).

    When checking out paths from the index, this option lets you
    recreate the conflicted merge in the specified paths.

(The last sentence is the most important one).

Here is a blog post that describes why it was added and how it is not possible with older versions of git: http://gitster.livejournal.com/43665.html

Monday, August 9, 2021
 
Axalix
answered 4 Months ago
35

Yes, for example:

git grep res -- '*.js'
Saturday, September 4, 2021
 
Adil Hussain
answered 3 Months ago
86

This workaround works for me:

GIT_WORK_TREE="$(git rev-parse --show-toplevel)" GIT_DIR="$(git rev-parse --git-dir)" git difftool --tool=meld --dir-diff

You can of course put in --cached as per your example.

That's quite a lot to type so you can add the following alias to your ~/.gitconfig:

[alias]
    submeld = !git --work-tree "$(git rev-parse --show-toplevel)" --git-dir "$(git rev-parse --git-dir)" difftool --tool=meld --dir-diff
Thursday, November 11, 2021
 
vuuduu
answered 3 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share