Re: [lmi] Navigate by color in `git-diff --color-moved=plain`

[Greg Chicares]

On 2019-04-24 21:13, Vadim Zeitlin wrote:
> On Wed, 24 Apr 2019 20:14:17 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> When making successive revisions to lmi's build system, I find it
> GC> useful to run a command like the following, which wipes everything
> GC> clean and then rebuilds the lmi world from scratch, in a 'set -vx'
> GC> script that echoes every step into a log file:
> GC> 
> GC> make raze; logfile=log-`date -u +'%Y%m%dT%H%MZ'`; echo "Log file is 
> '$logfile.tar.bz2'."; ./install_msw.sh >$logfile 2>&1; tar -cjf 
> $logfile.tar.bz2 $logfile; mv ${logfile}* ..
> GC> 
> GC> and then compare the latest log to the last known-good log.
> [...]
> GC> and indeed after '-r' I can search for '/[[]3[12]m'. But of course
> GC> '-r' makes everything the same color and shows escape sequences
> GC> literally, when ideally I'd like to see the colorized output but
> GC> search by (invisible) escape sequence. Does that seem possible?
> 
>  Is there anything wrong with the trivial solution of piping the diff
> through grep selecting only the red/green lines? This would lose all
> context, of course, but if the goal is to just check that there are no
> unexpected changes, this shouldn't matter.

Thanks, that sounds like exactly what I need.

>  I.e. perhaps you should try
> 
>       git diff --no-index --color=always --color-moved=plain ... |grep 
> '^.\[3[12]'|less

I had to add an '-R' at the end [as explained below]:

git diff --no-index --color=always --color-moved=plain \
  ../log-20190424T2109Z ../log-20190421T2325Z-good  |grep '^.\[3[12]' |less -R

It shouldn't be too hard to tell whether that changeset is ready
to push, now that I know that the only changed lines, ignoring
permutations, are:

-+ find /cache_for_lmi/downloads -type+  f
-xargs md5sum
++ find /cache_for_lmi/downloads -type f
++ xargs md5sum

which is just weird--the script line is
    find /cache_for_lmi/downloads -type f | xargs md5sum
and it's unchanged except for indentation since 2010; but maybe that's
just an artifact of 'set -vx'.

-+ winepath -w+  /opt/lmi/x86_64-w64-mingw32/local/lib
-sed -es/\\/\\\\/g
++ winepath -w /opt/lmi/x86_64-w64-mingw32/local/lib
++ sed -es/\\/\\\\/g

That's weird in the same way. Both logs print the sourced 'set_arch.sh',
and the relevant lines are identical:
        w0="$(winepath -w "$localbindir" | sed -e's/\\/\\\\/g')"
        w1="$(winepath -w "$locallibdir" | sed -e's/\\/\\\\/g')"
        w2="$(winepath -w "$winebindir"  | sed -e's/\\/\\\\/g')"

and the older log shows a regular trace, but the newer log traces
the middle ('w1') line differently:

+ winepath -w /opt/lmi/x86_64-w64-mingw32/local/bin
+ sed -es/\\/\\\\/g
+ w0=Z:\\opt\\lmi\\x86_64-w64-mingw32\\local\\bin
+ winepath -w+  /opt/lmi/x86_64-w64-mingw32/local/lib
sed -es/\\/\\\\/g
+ w1=Z:\\opt\\lmi\\x86_64-w64-mingw32\\local\\lib
+ winepath -w /opt/lmi/third_party/bin
+ sed -es/\\/\\\\/g
+ w2=Z:\\opt\\lmi\\third_party\\bin

Any idea what's going on there? I thought 'set -x' wrote "+\n" only
at the beginning of a traced line, but here:

+ winepath -w+  /opt/lmi/x86_64-w64-mingw32/local/lib
sed -es/\\/\\\\/g

it seems to have written the "\n" in the right place, but the
"+" too early.

> and see if this is enough? Note that I used "." as I'm not sure how to grep
> for U+001B, I can enter it as "Ctrl-V Esc" interactively, but this doesn't
> translate well to the email medium.
> 
>  Also, I use just less because I already have "-eiFRMX" in my LESS
> environment variable and I think so do you, but if you don't, you'd need to
> use at least "-R" explicitly to see the colours.

$env |grep LESS
LESSCHARSET=utf-8

$git config --list |grep pager
core.pager=less -+F -+X

https://www.git-scm.com/docs/git-config
| When the LESS environment variable is unset, Git sets it to FRX

I infer that, with these settings, git uses 'less -R' as its pager.

On 2019-04-24 21:22, Vadim Zeitlin wrote:> 
>  You could also just avoid colouring the moved lines in the first place by
> resetting their colours to the default, e.g.
> 
>       git -c color.diff.newMoved=white -c color.diff.oldMoved=white diff 
> --color-moved=plain ...
> 
> This preserves context, but makes the really changed lines stand out much
> more.

That's also useful. In this same context:

git -c color.diff.newMoved=white -c color.diff.oldMoved=white diff --no-index 
--color-moved=plain \
  -- ../log-20190424T2109Z ../log-20190421T2325Z-good

If I find the time, I think I could combine these ideas into something
better, thus:
 - produce the differences with escape codes
 - instead of filtering with "grep '^.\[3[12]'" as above, do something like
     | sed -e's/^.\[3[12]/ZZZ/' | ...
 - pipe the result back into 'less'; then just search for "ZZZ"
Actually, carrying out that plan is trivially easy, and this works great:

git diff --no-index --color=always --color-moved=plain \
  ../log-20190424T2109Z ../log-20190421T2325Z-good \
  |sed -e's/^.\[3[12]m/ZZZ/' |less -RS

I'm not ambitious enough to try using a non-printing character like ZWNJ
instead of the sufficiently unlikely string "ZZZ".