login
Search
Excellent ideas! I don't have anything to add ;-) This makes [1/2] a rather new patch though, I moved the whole prefix/suffix handing further out to accommodate different styles. There's a little change in [2/2] apart from the obvious option renaming, too: it interprets --color-words and --word-diff as an initial setting for the checkbox. Thomas Rast (2): diff: add --word-diff option that generalizes --color-words gitk: add the equivalent of diff --color-words --
Use the newly added 'diff --word-diff=porcelain' to teach gitk a
color-words mode, triggered by a checkbox.
As an extra twist, automatically enable this word-diff support when
the user mentions a word-diff related option on the command line.
These options were previously ignored because they would break diff
parsing.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
gitk | 37 ++++++++++++++++++++++++++++++++++---
1 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 1f36a3e..05ed053 100755
--- a/gitk
+++ b/gitk
@@ -131,6 +131,7 @@ proc unmerged_files {files} {
proc parseviewargs {n arglist} {
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+ global worddiff
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -168,7 +169,7 @@ proc parseviewargs {n arglist} {
lappend diffargs $arg
}
"--raw" - "--patch-with-raw" - "--patch-with-stat" -
- "--name-only" - "--name-status" - "--color" - "--color-words" -
+ "--name-only" - "--name-status" - "--color" -
"--log-size" - "--pretty=*" - "--decorate" - "--abbrev-commit" -
"--cc" - "-z" - "--header" - "--parents" - "--boundary" -
"--no-color" - "-g" - "--walk-reflogs" - "--no-walk" -
@@ -177,6 +178,11 @@ proc parseviewargs {n arglist} {
# These cause our parsing of git log's output to fail, or else
# they're options we want to set ourselves, so ignore them.
}
+ "--color-words*" - "--word-diff*" {
+ # These trigger a word diff in the console interface,
+ # so help the user by enabling our own support
+ set worddiff 1
+ }
"--stat=*" - "--numstat" - "--shortstat" - "--summary" -
"--check" - "--exit-code" - "--quiet" - "--topo-order" -
"--full-history" - "--dense" - "--sparse" -
@@ -2240,6 +2246,9 @@ proc makewindow {} {
${NS}::checkbutton .bleft.mid.ignspace -text [mc "Ignore space change"] \
-command changeignorespace -variable ignorespace
pack ...This teaches the --color-words engine a more general interface that
supports two new modes:
* --word-diff=plain, inspired by the 'wdiff' utility (most similar to
'wdiff -n <old> <new>'): uses delimiters [-removed-] and {+added+}
* --word-diff=porcelain, which generates an ad-hoc machine readable
format:
- each diff unit is prefixed by [-+ ] and terminated by newline as
in unified diff
- newlines in the input are output as a line consisting only of a
tilde '~'
--color-words becomes a synonym for --word-diff=color. Also adds some
compatibility/convenience options.
Thanks to Junio C Hamano and Miles Bader for good ideas.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/diff-options.txt | 39 +++++++++-
Documentation/gitattributes.txt | 2 +-
color.c | 28 -------
color.h | 1 -
diff.c | 148 ++++++++++++++++++++++++++++++++++-----
diff.h | 11 +++-
t/t4034-diff-words.sh | 70 ++++++++++++++++++
7 files changed, 245 insertions(+), 54 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 60e922e..e51fc9a 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -126,11 +126,38 @@ any of those replacements occurred.
gives the default to color output.
Same as `--color=never`.
---color-words[=<regex>]::
- Show colored word diff, i.e., color words which have changed.
- By default, words are separated by whitespace.
+--word-diff[=<mode>]::
+ Show a word diff, using the <mode> to delimit changed words.
+ By default, words are delimited by whitespace; see
+ `--word-diff-regex` below. The <mode> defaults to 'auto', and
+ must be one of:
++
+--
+color::
+ Highlight changed words with colors. Implies `--color`.
+plain::
+ Show words as `[-removed-]` and `{+added+}`. Makes no
+ attempts to escape the delimiters if they appear in the ...Thanks. This was a fun feature to look at.
I think it is a bug that "git show --word-diff" gives the colored format
output when I have "color.ui" configuration.
Even though I may have "color.ui = auto" in the configuration, I am
telling the command to do a --word-diff, not --color-words, from the
command line, and that should override color.ui settings.
So I think a request for --word-diff that is not --word-diff=color should
never use the --color-words _unless_ there is --color on the command line:
git show --word-diff
git show --word-diff=plain
git show --word-diff=porcelain
All of the above may paint hunk headers and metainfo the usual way when I
have "color.ui" set, but I do not want them to be painting the diff part
like --color-words does. I am fine if "porcelain" did not to paint the
metainfo, but I see this feature as three different output types of how
word diff is presented, so in that sense, it probably is better to force
scripts to explicitly ask for no-color, i.e.
git show --no-color --word-diff=porcelain
if they want to read and interpret metainfo.
When the command line asks for color explicitly, then we should see the
good old --color-words:
git show --color-words
git show --word-diff=color
I am not sure what the following two should do. One could argue that
these default to --color-words; or --color should apply only to the
coloring of metainfo but not the diff part:
git show --color --word-diff
git show --word-diff --color
I am slightly in favor of doing the same as --color-words, but people may
have different opinions.
The following of course should show the plain word diff but the metainfo
and friends colored:
git show --word-diff=plain --color
git show --color --word-diff=plain
It might be just the matter of defaulting --word-diff without "=<type>"
not to "auto" but to "plain". I haven't looked at the code closely yet.
--
I don't really see why the user would forfeit the convenience and
readability of a color-words diff when the terminal supports colors.
Granted, this is probably the first instance where the colors actually
change the output format instead of just making easier to read, but
still?
Yes.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
There is one difference between other uses of colors and color-words, but
I can imagine that ordinary people may not have even realized nor thought
about it.
To people who are somewhat but not completely color-challenged (like
myself), it still helps to paint hunk headers in a color that is different
from the body text to make the boundary of each hunk more visible. Even
without the perception of exact color/hue, the contrast alone helps in
that case.
The body of the diff is painted in deleted and added colors; the color is
used only as a way to additionally enhance the output, while still keeping
the plus/minus/SP at the leftmost column. Even to somebody who is
completely color challenged, the necessary information is still there.
Compare --color-words with these. The output uses color as the _only_ way
to say which words appear before and after. The contrast among the three
colors used for the plain body, deleted and added text may still help, or
it may not, to a partially color challenged person.
I also happen to see "--word-diff=color" more as just a customization to
the "plain" output formatting to say "use these byte sequences that happen
to be ANSI color codes, instead of '{+', '+}', etc." than as a part of
what the ui.color switch wants to specify, which is "are various parts of
the output colored to further help distinguishing them visually?"
So color me somewhat biased, but there is a case where the suggestion in
the message you are responding to makes a difference.
I also think --color --word-diff=plain could show "{+new+}" in green and
"[-old-]" in red and that may make things more consistent.
--
I agree. For some reason, even though I can see the red and green well enough, I find the current --color-words output hard to parse. The use of _only_ color to distinguish old/new somehow doesn't jive with my brain... I find _highlighting_ using color very useful, but I think using syntax and color together is better than using just color. -Miles -- Do not taunt Happy Fun Ball. --
During development an unrelated gitk diff parsing bug hit me, which is the new 2/3. I think it should go in maint if the patch turns out to be correct, but I'd like to have an ACK from Jens first. So here's a patch that does that. I may be overdoing the "generic diff style" code a bit, but it makes for slightly nicer code. I similarly extended the support in gitk to have two different modes. My use of the dropdown is again sheer voodoo and works merely by accident... I also taught gitk to not show the option and not parse the command-line options unless the git version is at least v1.7.2, which I expect will be the version that has the underlying diff support. BTW: I set my diff colors to bold red/blue which makes the changed words very visible even in light conditions where green is very hard to tell Well, I for one find the extra markup *very* confusing because I need to mentally untangle it from the actual content... Thomas Rast (3): diff: add --word-diff option that generalizes --color-words gitk: do not parse " >" context as submodule change gitk: add the equivalent of diff --color-words --
Since 5c838d2 (gitk: Use the --submodule option for displaying diffs
when available, 2009-10-28) gitk erroneously matches " >" and " <"
at the beginning of a line in the submodule code even if we're in the
diff text section and the lines should be treated as context.
Fix by (ab)using the $diffinhdr variable also in the 'Submodule...'
case, and move the " >"/" <" specific code inside the $diffinhdr
test. The existing code will set $diffinhdr to 0 when it hits a
"+++", so that it is always 0 when we can hit a context line.
---
gitk | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index 1f36a3e..e9e284e 100755
--- a/gitk
+++ b/gitk
@@ -7688,12 +7688,8 @@ proc getblobdiffline {bdf ids} {
lappend ctext_file_lines $fname
makediffhdr $fname $ids
$ctext insert end "\n$line\n" filesep
- } elseif {![string compare -length 3 " >" $line]} {
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" dresult
- } elseif {![string compare -length 3 " <" $line]} {
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" d0
+ # pretend we're in a file header to correctly parse " [><]"
+ set diffinhdr 1
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
@@ -7712,6 +7708,12 @@ proc getblobdiffline {bdf ids} {
set fname [lindex $fname 0]
}
makediffhdr $fname $ids
+ } elseif {![string compare -length 3 " >" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" dresult
+ } elseif {![string compare -length 3 " <" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" d0
} elseif {[string compare -length 3 $line "---"] == 0} {
# do nothing
continue
--
1.7.1.rc0.262.gff1a3
--
Since 5c838d2 (gitk: Use the --submodule option for displaying diffs
when available, 2009-10-28) gitk erroneously matches " >" and " <"
at the beginning of a line in the submodule code even if we're in the
diff text section and the lines should be treated as context.
Fix by (ab)using the $diffinhdr variable also in the 'Submodule...'
case, and move the " >"/" <" specific code inside the $diffinhdr
test. The existing code will set $diffinhdr to 0 when it hits a
"+++", so that it is always 0 when we can hit a context line.
---
I just noticed that I forgot to add the 'continue' that prevents the
final 'insert' in the $diffinhdr block from kicking in, which resulted
in doubling of the lines. This one has them. Sorry for the noise.
gitk | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index 1f36a3e..7b8799e 100755
--- a/gitk
+++ b/gitk
@@ -7688,12 +7688,8 @@ proc getblobdiffline {bdf ids} {
lappend ctext_file_lines $fname
makediffhdr $fname $ids
$ctext insert end "\n$line\n" filesep
- } elseif {![string compare -length 3 " >" $line]} {
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" dresult
- } elseif {![string compare -length 3 " <" $line]} {
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" d0
+ # pretend we're in a file header to correctly parse " [><]"
+ set diffinhdr 1
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
@@ -7712,6 +7708,14 @@ proc getblobdiffline {bdf ids} {
set fname [lindex $fname 0]
}
makediffhdr $fname $ids
+ } elseif {![string compare -length 3 " >" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" dresult
+ continue
+ } elseif {![string compare -length 3 " <" $line]} {
+ set line ...Use the newly added 'diff --word-diff=porcelain' to teach gitk a
color-words mode, with two different modes analogous to the
--word-diff=plain and --word-diff=color settings. These are selected
by a dropdown box.
As an extra twist, automatically enable this word-diff support when
the user mentions a word-diff related option on the command line.
These options were previously ignored because they would break diff
parsing.
Both of these features are only enabled if we have a version of git
that supports --word-diff=porcelain, tentatively set to 1.7.2.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
gitk | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index e9e284e..466c328 100755
--- a/gitk
+++ b/gitk
@@ -131,6 +131,7 @@ proc unmerged_files {files} {
proc parseviewargs {n arglist} {
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+ global worddiff git_version
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -168,7 +169,7 @@ proc parseviewargs {n arglist} {
lappend diffargs $arg
}
"--raw" - "--patch-with-raw" - "--patch-with-stat" -
- "--name-only" - "--name-status" - "--color" - "--color-words" -
+ "--name-only" - "--name-status" - "--color" -
"--log-size" - "--pretty=*" - "--decorate" - "--abbrev-commit" -
"--cc" - "-z" - "--header" - "--parents" - "--boundary" -
"--no-color" - "-g" - "--walk-reflogs" - "--no-walk" -
@@ -177,6 +178,18 @@ proc parseviewargs {n arglist} {
# These cause our parsing of git log's output to fail, or else
# they're options we want to set ourselves, so ignore them.
}
+ "--color-words*" - "--word-diff=color" {
+ # These trigger a word diff in the console interface,
+ # so help the user by enabling our own support
+ if {[package vcompare $git_version "1.7.2"] >= 0} {
+ set worddiff [mc "Color words"]
+ }
+ }
+ ...This teaches the --color-words engine a more general interface that
supports two new modes:
* --word-diff=plain, inspired by the 'wdiff' utility (most similar to
'wdiff -n <old> <new>'): uses delimiters [-removed-] and {+added+}
* --word-diff=porcelain, which generates an ad-hoc machine readable
format:
- each diff unit is prefixed by [-+ ] and terminated by newline as
in unified diff
- newlines in the input are output as a line consisting only of a
tilde '~'
Both of these formats still support color if it is enabled, using it
to highlight the differences. --color-words becomes a synonym for
--word-diff=color, which is the color-only format. Also adds some
compatibility/convenience options.
Thanks to Junio C Hamano and Miles Bader for good ideas.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/diff-options.txt | 40 +++++++++-
Documentation/gitattributes.txt | 2 +-
color.c | 28 -------
color.h | 1 -
diff.c | 154 ++++++++++++++++++++++++++++++++++-----
diff.h | 10 ++-
t/t4034-diff-words.sh | 122 +++++++++++++++++++++++++++++++
7 files changed, 303 insertions(+), 54 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 60e922e..a616ca5 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -126,11 +126,39 @@ any of those replacements occurred.
gives the default to color output.
Same as `--color=never`.
---color-words[=<regex>]::
- Show colored word diff, i.e., color words which have changed.
- By default, words are separated by whitespace.
+--word-diff[=<mode>]::
+ Show a word diff, using the <mode> to delimit changed words.
+ By default, words are delimited by whitespace; see
+ `--word-diff-regex` below. The <mode> defaults to 'plain', and
+ must be one of:
++
+--
+color::
+ Highlight changed words using only ...Beautiful.
The style might be a bit iffy. Shouldn't an opening "{", unless closed on
I would avoid strlen() only for boolean result here---the compilers may
not be as clever as you are.
if (st_elp->color && *st_elp->color
--
Perhaps. OTOH I just noticed I could also drop the NULL (and let the
implicit 0-padding take over) which makes every style fit on a single
No, thanks for catching this.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
This merely addresses Junio's comments on 1/3 of the last round, since I haven't heard anything about the gitk patches. Thomas Rast (3): diff: add --word-diff option that generalizes --color-words gitk: do not parse " >" context as submodule change gitk: add the equivalent of diff --color-words --
This teaches the --color-words engine a more general interface that
supports two new modes:
* --word-diff=plain, inspired by the 'wdiff' utility (most similar to
'wdiff -n <old> <new>'): uses delimiters [-removed-] and {+added+}
* --word-diff=porcelain, which generates an ad-hoc machine readable
format:
- each diff unit is prefixed by [-+ ] and terminated by newline as
in unified diff
- newlines in the input are output as a line consisting only of a
tilde '~'
Both of these formats still support color if it is enabled, using it
to highlight the differences. --color-words becomes a synonym for
--word-diff=color, which is the color-only format. Also adds some
compatibility/convenience options.
Thanks to Junio C Hamano and Miles Bader for good ideas.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/diff-options.txt | 40 ++++++++++-
Documentation/gitattributes.txt | 2 +-
color.c | 28 --------
color.h | 1 -
diff.c | 139 +++++++++++++++++++++++++++++++++-----
diff.h | 10 +++-
t/t4034-diff-words.sh | 122 ++++++++++++++++++++++++++++++++++
7 files changed, 288 insertions(+), 54 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 60e922e..a616ca5 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -126,11 +126,39 @@ any of those replacements occurred.
gives the default to color output.
Same as `--color=never`.
---color-words[=<regex>]::
- Show colored word diff, i.e., color words which have changed.
- By default, words are separated by whitespace.
+--word-diff[=<mode>]::
+ Show a word diff, using the <mode> to delimit changed words.
+ By default, words are delimited by whitespace; see
+ `--word-diff-regex` below. The <mode> defaults to 'plain', and
+ must be one of:
++
+--
+color::
+ Highlight changed words using ...Looks good; I'll queue this one and hopefully Paul can give feedback to the gitk patches. Thanks. --
Use the newly added 'diff --word-diff=porcelain' to teach gitk a
color-words mode, with two different modes analogous to the
--word-diff=plain and --word-diff=color settings. These are selected
by a dropdown box.
As an extra twist, automatically enable this word-diff support when
the user mentions a word-diff related option on the command line.
These options were previously ignored because they would break diff
parsing.
Both of these features are only enabled if we have a version of git
that supports --word-diff=porcelain, tentatively set to 1.7.2.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
gitk | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 7b8799e..f2a1eb7 100755
--- a/gitk
+++ b/gitk
@@ -131,6 +131,7 @@ proc unmerged_files {files} {
proc parseviewargs {n arglist} {
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+ global worddiff git_version
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -168,7 +169,7 @@ proc parseviewargs {n arglist} {
lappend diffargs $arg
}
"--raw" - "--patch-with-raw" - "--patch-with-stat" -
- "--name-only" - "--name-status" - "--color" - "--color-words" -
+ "--name-only" - "--name-status" - "--color" -
"--log-size" - "--pretty=*" - "--decorate" - "--abbrev-commit" -
"--cc" - "-z" - "--header" - "--parents" - "--boundary" -
"--no-color" - "-g" - "--walk-reflogs" - "--no-walk" -
@@ -177,6 +178,18 @@ proc parseviewargs {n arglist} {
# These cause our parsing of git log's output to fail, or else
# they're options we want to set ourselves, so ignore them.
}
+ "--color-words*" - "--word-diff=color" {
+ # These trigger a word diff in the console interface,
+ # so help the user by enabling our own support
+ if {[package vcompare $git_version "1.7.2"] >= 0} {
+ set worddiff [mc "Color words"]
+ }
+ }
+ ...Looks fine. The only nit I can see is that a "--word-diffoobar" option would get treated as "--word-diff=plain" rather than giving an error or being passed as-is to git log. When does this need to go in, i.e. when is the git patch likely to go in? Paul. --
I am expecting that this will be in soon after the current 1.7.1 cycle, sometime around early-to-mid May timeframe. --
Since 5c838d2 (gitk: Use the --submodule option for displaying diffs
when available, 2009-10-28) gitk erroneously matches " >" and " <"
at the beginning of a line in the submodule code even if we're in the
diff text section and the lines should be treated as context.
Fix by (ab)using the $diffinhdr variable also in the 'Submodule...'
case, and move the " >"/" <" specific code inside the $diffinhdr
test. The existing code will set $diffinhdr to 0 when it hits a
"+++", so that it is always 0 when we can hit a context line.
---
gitk | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index 1f36a3e..7b8799e 100755
--- a/gitk
+++ b/gitk
@@ -7688,12 +7688,8 @@ proc getblobdiffline {bdf ids} {
lappend ctext_file_lines $fname
makediffhdr $fname $ids
$ctext insert end "\n$line\n" filesep
- } elseif {![string compare -length 3 " >" $line]} {
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" dresult
- } elseif {![string compare -length 3 " <" $line]} {
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" d0
+ # pretend we're in a file header to correctly parse " [><]"
+ set diffinhdr 1
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
@@ -7712,6 +7708,14 @@ proc getblobdiffline {bdf ids} {
set fname [lindex $fname 0]
}
makediffhdr $fname $ids
+ } elseif {![string compare -length 3 " >" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" dresult
+ continue
+ } elseif {![string compare -length 3 " <" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" d0
+ continue
} elseif {[string compare -length 3 $line "---"] == 0} {
# do nothing
continue
-- ...Thanks for fixing this issue I accidentally introduced!
In that said patch I unfortunately also managed to screw up the
submodule name detection when it was not followed just by commits
(but e.g. by "contains untracked content"). I did already send a
patch to address this issue, but here is a rebased version on top
of your patch series just in case:
--------------------8<--------------------
From: Jens Lehmann <Jens.Lehmann@web.de>
Date: Thu, 15 Apr 2010 21:53:12 +0200
Subject: [PATCH] Teach gitk to display dirty submodules correctly
Since 1.7.1 "git diff --submodule" prints out extra lines when the
submodule contains untracked or modified files. Show all those lines for
one submodule under the same header.
Also e.g. for newly added or removed submodules the submodule name
contained trailing garbage because the extraction of the name was not
done right. Now it scans either for the first hex number followed by a
".." or the string "contains ".
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
gitk-git/gitk | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index f2a1eb7..93d25ec 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7530,7 +7530,7 @@ proc getblobdiffs {ids} {
global worddiff
global limitdiffs vfilelimit curview
global diffencoding targetline diffnparents
- global git_version
+ global git_version currdiffsubmod
set textconv {}
if {[package vcompare $git_version "1.6.1"] >= 0} {
@@ -7560,6 +7560,7 @@ proc getblobdiffs {ids} {
set diffencoding [get_path_encoding {}]
fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
set blobdifffd($ids) $bdf
+ set currdiffsubmod ""
filerun $bdf [list getblobdiffline $bdf $diffids]
}
@@ -7631,7 +7632,7 @@ proc getblobdiffline {bdf ids} {
global ctext_file_names ctext_file_lines
global diffinhdr treediffs mergemax diffnparents
global diffencoding ...Looks good, but there's no Signed-off-by? Paul. --
Whoops, sorry:
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
Thanks, but now that I have applied Jens Lehmann's patch that also touches this area, your patch doesn't apply. Could you rebase it and send it again? Thanks, Paul. --
Since 5c838d2 (gitk: Use the --submodule option for displaying diffs
when available, 2009-10-28) gitk erroneously matches " >" and " <"
at the beginning of a line in the submodule code even if we're in the
diff text section and the lines should be treated as context.
Fix by (ab)using the $diffinhdr variable also in the 'Submodule...'
case, and move the " >"/" <" specific code inside the $diffinhdr
test. The existing code will set $diffinhdr to 0 when it hits a
"+++", so that it is always 0 when we can hit a context line.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Sure.
gitk | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/gitk b/gitk
index 1b0e09a..6513ef8 100755
--- a/gitk
+++ b/gitk
@@ -7706,14 +7706,8 @@ proc getblobdiffline {bdf ids} {
} else {
$ctext insert end "$line\n" filesep
}
- } elseif {![string compare -length 3 " >" $line]} {
- set $currdiffsubmod ""
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" dresult
- } elseif {![string compare -length 3 " <" $line]} {
- set $currdiffsubmod ""
- set line [encoding convertfrom $diffencoding $line]
- $ctext insert end "$line\n" d0
+ # pretend we're in a file header to correctly parse " [><]"
+ set diffinhdr 1
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
@@ -7732,6 +7726,14 @@ proc getblobdiffline {bdf ids} {
set fname [lindex $fname 0]
}
makediffhdr $fname $ids
+ } elseif {![string compare -length 3 " >" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" dresult
+ continue
+ } elseif {![string compare -length 3 " <" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
+ $ctext insert end "$line\n" d0
+ continue
} elseif {[string compare -length 3 $line ...Use the newly added 'diff --word-diff=porcelain' to teach gitk a
color-words mode, with two different modes analogous to the
--word-diff=plain and --word-diff=color settings. These are selected
by a dropdown box.
As an extra twist, automatically enable this word-diff support when
the user mentions a word-diff related option on the command line.
These options were previously ignored because they would break diff
parsing.
Both of these features are only enabled if we have a version of git
that supports --word-diff=porcelain, tentatively set to 1.7.2.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
gitk | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 6513ef8..46d1b0e 100755
--- a/gitk
+++ b/gitk
@@ -131,6 +131,7 @@ proc unmerged_files {files} {
proc parseviewargs {n arglist} {
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+ global worddiff git_version
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -168,7 +169,7 @@ proc parseviewargs {n arglist} {
lappend diffargs $arg
}
"--raw" - "--patch-with-raw" - "--patch-with-stat" -
- "--name-only" - "--name-status" - "--color" - "--color-words" -
+ "--name-only" - "--name-status" - "--color" -
"--log-size" - "--pretty=*" - "--decorate" - "--abbrev-commit" -
"--cc" - "-z" - "--header" - "--parents" - "--boundary" -
"--no-color" - "-g" - "--walk-reflogs" - "--no-walk" -
@@ -177,6 +178,18 @@ proc parseviewargs {n arglist} {
# These cause our parsing of git log's output to fail, or else
# they're options we want to set ourselves, so ignore them.
}
+ "--color-words*" - "--word-diff=color" {
+ # These trigger a word diff in the console interface,
+ # so help the user by enabling our own support
+ if {[package vcompare $git_version "1.7.2"] >= 0} {
+ set worddiff [mc "Color words"]
+ }
+ }
+ ...There might be a problem with this rebase. Unfortunately I am very short on time, so I can't test this today. I think setting the $currdiffsubmod variable to the empty string has to show up in the two sections formatting the lines with If you can wait until tomorrow I can check that. --
I successfully tested this patch, this was a false alarm from my side. Sorry for the noise. Tested-by: Jens.Lehmann@web.de --
I see now. My apologies for not thinking of that case!
I'll make a new patch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
