1

Context:

Often while investigating an issue, I will introduce debugging statements (isolated from the solution, in their own commits), and then once I have a solution I will remove all these debug statements. Sometimes, however, when viewing a diff or a blame, it is unclear which changes were introduced in debugging and which were intended as part of the solution. In this case I would like to determine, for any specific commit or set of commits, which lines (if any) were changed in that commit and not changed again later. This way I can be sure that all of the debug changes have been correctly reverted.

Ordinarily, I would simply revert the commits through git, but especially when spending a long time on a solution, alternating between fixing and debugging, there will likely be code-changing commits which remove lines introduced in debugging, making git revert non-trivial.

Summary:

I would like to see any lines in any files in a repository, which would be labelled with one of a specific set of commits in a git blame. That is to say, any lines which were touched by a given commit and not changed since. Currently, my workflow is as follows:

git log
#record short hashes of the commits i'm interested in

for each hash:

git show --name-only $hash
#record files affected

for each file:

git blame -- "$file" | grep $hash
Zoey Hewll
  • 4,788
  • 2
  • 20
  • 33

2 Answers2

0

I've made a rather complex command built with xargs and grep and stringing together git commands, but that seems like overkill and I'd hope there's a way to do this that mostly delegates to git.

This accepts a list of abbreviated hashes as its arguments:

RE="`echo "$*" | sed 's: :\\|:g'`"
git show --pretty=format: --name-only "$@"
    | sed '/^$/d'
    | sort
    | uniq
    | xargs -l git blame --
    | grep "$RE"

However if there are any affected lines, it won't tell you what file they were from.
It also cannot find affected lines if given a full hash: the abbreviation needs to be supplied.

Zoey Hewll
  • 4,788
  • 2
  • 20
  • 33
0

I think git diff HEAD [Commit before first debug change] should do.

You can view the outcome in an text editor and search for the debug changes. If you find any it has not yet been removed.

Timothy Truckle
  • 15,071
  • 2
  • 27
  • 51
  • The reason I want to know which commit introduced each line is that sometimes there are so many changes, and the debug changes are so similar in appearance to the necessary changes, that I can't tell them apart by inspection, or doing so would be tedious. – Zoey Hewll Jul 19 '18 at 09:11
  • Then you should start to commit you debug changes separately. Then you can easiy identify them by filtering the commit messages. After all the tool is *smart* but not *intelligent*. It cannot know what you had in mind by changing a certain piece of code unless you tell it... – Timothy Truckle Jul 19 '18 at 09:14
  • That is exactly what I have done. I will edit my question to make this clear. – Zoey Hewll Jul 19 '18 at 09:16