![]() (I tried restricting the revision filter more, but I ran into problems and don't recommend this. Git log -merges -pretty=format:"git diff %h^.%h | grep target_text" HEAD ^$(git merge-base A B) | sh -v 2>&1 | less The -U9999 is meant to show the entire file contents (after each time the file was changed), assuming your files are all max 9999 lines.įinds any related merges via brute force (diff each possible merge commit with its first parent, run against tons of commits) The second commit might be the one that removed it. The second "^commit" is after it disappeared. Search for the change, then search backwards for "^commit" - the first "^commit" is the commit where the file last had that line. The file git log -p - path/file history only showed it being added. So the line I wanted had been added and later removed and I wanted to find the merge which removed it. Both pickaxe and reverse-blame did not find the change. Merge commits automatically have their changes hidden from the Git log output. OTOH, if the following revision is a merge commit, then things can get a little wild.Īs part of the effort to create difflame I tackled this very problem so if you already have Python installed on your box and you are willing to give it a try, then don't wait any longer and let me know how it goes. Then if the following revision is a plain commit, you are lucky and you got the deleting revision. It points to the last revision where the line was present. But it actually doesn't point to the revision where the line is deleted. Git blame -reverse can get you close to where the line is deleted. The -full-history flag prevents skipping those commits. I had the same problem as mentioned here, but it turned out that the line was missing, because a merge commit from a branch got reverted and then merged back into it, effectively removing the line in question. Just to complete Cascabel's answer: git log -full-history -S path/to/file git log -reverse -ancestry-path COMMIT^.master The first commit shown will be the last time that line appears, and the next commit will be when it is changed or removed. You can use the following command to show a reversed git log. ![]() You still need to get the commit that comes after. With git blame reverse, you can find the last commit the line appeared in. This requires a range of revisions like START.END where the path to blame exists in START. Instead of showing the revision in which a line appeared, this shows the last revision in which a line has existed. Walk history forward instead of backward. I think what you really want is git blame -reverse START.END filename The -S option is actually mentioned in the header of the git-blame manpage too, in the description section, where it gives an example using git log -S. There's also the -G which does the same thing with regular expressions! See man git-log and search for the -G and -S options, or pickaxe (the friendly name for these features) for more information. Which shows you commits which introduce or remove an instance of that string. If you know the contents of the line, this is an ideal use case for: git log -S path/to/file ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |