git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Using --word-diff breaks --color-moved

From
JHjames harvey <jamespharvey20@gmail.com>
Date
Nov 2, 2018, 01:18 UTC
Message-ID
<CA+X5Wn6nP5sZh8Z2dcTZKpPBWG43nSUATcWx0fzp2dNTJ3UzQQ@mail.gmail.com>
In-Reply-To
<CAGZ79kZ6LxRevLy2mZd1Ag=oO_NtDdmRSuadswR_n=RGpO=rGQ@mail.gmail.com>
On Wed, Oct 31, 2018 at 1:42 PM Stefan Beller <sbeller@google.com> wrote:
Show 13 quoted lines
>
> On Tue, Oct 30, 2018 at 7:06 PM james harvey <jamespharvey20@gmail.com> wrote:
> > I think "--color-moved" should have precedence over "--word-diff".
>
> I agree for precedence as in "work well together". Now we'd need
> to figure out what that means. In its current form, the move
> detection can detect moved lines across diff hunks or file
> boundaries.
>
> Should that also be the case for word diffing?
> I think word diffing is mostly used for free text, which has different
> properties compared to code, that the color-moved was originally
> intended for.

That's how I think of it too. I think I'd be fine if word diffing stayed not being able to be detected with moved lines across diff hunks or file boundaries.

Show 10 quoted lines
> >   I
> > cannot think of a scenario where a user would supply both options, and
> > actually want "--word-diff" to take precedence.  If I'm not thinking
> > of a scenario where this wouldn't be desired, perhaps whichever is
> > first as an argument could take precedence.
>
> word diffing and move detection are completely orthogonal at the moment.
> Instead of option order, I'd rather introduce a new option that tells us
> how to resolve some corner case. Or in the short term we might just
> want to raise an error?

I'm fine with option order not mattering, as it does now. Was assuming it didn't matter now, but mentioned trying it in case it worked that way. And, mentioned it as an alternative in case it turned out the two could conflict in some corner case. I think defaulting to resolving one way or the other with an optional option to go the other way makes sense.

Show 10 quoted lines
> > (The same behavior happens if 4+ lines are moved and
> > "--color-moved{default=zebra}" is used, but below
> > "--color-moved=plain" is used to be a smaller testcase.)
> >
> > [...]
>
> This sounds like you are asking for two things:
> (1) make color-moved work with words (somehow)
> (2) allow the user to fine tune the heuristics for a block,
>     such that default=zebra would still work.

I was asking for #1. #2 might be a good idea, but I just tried using "--color-moved" for the first time the other day, so haven't used it enough to get that far. If they worked together, I'm not sure yet if I'd be using plain or zebra. I mentioned "4+ lines" because I can remember something said zebra only worked with more than 3 lines. Not sure where that was. I thought it was the manpage, but I'm not seeing that in there now.

Previous: Stefan BellerNext: Stefan Beller
Message 6 of 7 in “Using --word-diff breaks --color-moved”
  1. james harveyOct 31, 2018
  2. Junio C HamanoOct 31, 2018
  3. james harveyOct 31, 2018
  4. Stefan BellerOct 31, 2018
  5. Stefan BellerOct 31, 2018
  6. james harveyNov 2, 2018
  7. Stefan BellerNov 2, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.