I quite often find myself making a small change to a file that takes a long time time to run. The workflow is something like this:
<small edit to foo>
git add foo
<comment out huge swathe of foo which doesn't need testing>
<test change>
git restore foo
Works well. The only thing is, I like to check before git restore
-ing that the commenting is the only change that will be lost. And it's here that I feel let down by git, and most of the other many diff tools I've configured git with.
I would expect that viewing a diff between a block of code in the index like this:
#
# JIRA-001: Do a thing
#
foo <<-EOF
foo1
EOF
#
# JIRA-002: Do another thing
#
foo <<-EOF
foo2
EOF
and a working copy that looks like this:
##
## JIRA-001: Do a thing
##
#
#foo <<-EOF
# foo1
#EOF
#
##
## JIRA-002: Do another thing
##
#
#foo <<-EOF
# foo2
#EOF
would make it trivial to see that the difference is simply that a hash has been prepended to a range of lines. But it's often not straightforward to tell, as the diff is presented in multiple hunks of removed and added lines, sometimes interleaved in such a way as to leave me unclear if an additional change has found it's way in.
In addition to running git diff
I have also tried `git diff --word-diff-regex=. with somewhat better, but still to my mind not ideal, results. I have also tried all the different values for --diff-algorithm which makes no difference.
Can anyone suggest a way of viewing these diffs that will circumvent this issue?
Attaching partial outputs of git diff
and git diff --word-diff-regex=.
for comparison.
CodePudding user response:
To avoid the rampant punning, use a more distinguishable marker and tell the word diff about it:
$ git diff --word-diff-regex='#.|.' test test2
diff --git a/test b/test2
index 11c83b7..d92fc45 100644
--- a/test
b/test2
@@ -1,15 1,15 @@
{ #x }#
{ #x }# JIRA-001: Do a thing
{ #x }#
{ #x }
{ #x }foo <<-EOF
{ #x } foo1
{ #x }EOF
{ #x }
{ #x }#
{ #x }# JIRA-002: Do another thing
{ #x }#
{ #x }
{ #x }foo <<-EOF
{ #x } foo2
{ #x }EOF