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

Re: [PATCH] git-add--interactive.perl: Permit word-based diff

From
MAMark Abraham <mark.j.abraham@gmail.com>
Date
Jun 18, 2013, 21:12 UTC
Message-ID
<CAMNuMATdbhgydx5R0+OgSECqxs9tYgwqEjMuXq-0LV8fNaRWZw@mail.gmail.com>
In-Reply-To
<20130618172300.GA3557@sigill.intra.peff.net>
On Tue, Jun 18, 2013 at 7:23 PM, Jeff King <peff@peff.net> wrote:
Show 11 quoted lines
> On Tue, Jun 18, 2013 at 09:22:16AM +0200, Thomas Rast wrote:
>
>> [I don't seem to have received a copy of the original mail, so I can
>> only guess...]
>
> Yes, the original doesn't seem to have made it to the list. Sorry, I
> don't have a copy (I am in the habit of deleting direct mails that are
> cc'd to the list, as I keep a separate list archive).
>
> Mark, did you happen to send an HTML mail? The list will silently
> reject such mail.

Yes, that was probably it. I tried to find a gmail configuration, but I now discover it is done per-email, not globally. Apologies. I have forwarded the original to Thomas, but based on current feedback, it seems not worth re-sending the original mail to the list. See below.

Show 18 quoted lines
>> > Note that the number of lines in your --word-diff=color hunk and the
>> > actual diff will not necessarily be the same.  What happens if I split a
>> > hunk with your patch?
>>
>> If it's actually what you hint at, there's another problem: the word
>> diff might not even have the same number of hunks.  For example, a
>> long-standing bug (or feature, depending on POV) of word-diff is that it
>> does not take opportunities to completely drop hunks that did not make
>> any word-level changes.
>
> Yeah, I didn't even think of that.
>
> In general, I think one can assume 1-to-1 correspondence between whole
> regular diffs and whole word-diffs, but not below that (i.e., neither a
> correspondence between hunks nor between lines).
>
> With something like contrib/diff-highlight, you get some decoration, and
> can assume a 1-to-1 line correspondence.

My choice of "permit" in the description was not best. My implementation showed a word-based diff, but preserved the existing mechanism for actually applying the hunk. I understand the way colorization in git-add--interactive.perl works right now is to colorize one version to display and use another - I think I preserved that. I intended to permit the user to choose to show a word-based diff of a patch during interactive add.

Show 6 quoted lines
> However, I think that when reviewing text (especially re-wrapped
> paragraphs) that word-diff can be much easier to read, _because_ it
> throws away the line correspondence. To be correct, though, I think we
> would have to simply show the whole word-diff for a file and say "is
> this OK?". Which sort of defeats the purpose of "add -p" as a hunk
> selector (you could just as easily run "git diff --color-words foo" and

Hmm, I will have to re-consider the implications on that kind of workflow. Thanks!

> "git add foo"). But it does save keystrokes if your workflow is to
> simply "add -p" everything to double-check it before adding.
Yes, that was what I was aiming to make easier.
> So I dunno. I could see myself using it, but I certainly wouldn't want a
> config variable that turns it on all the time (which is what the
> original patch did).

Good point. What I think I really want is "git add --interactive=color" (with or without --patch) to permit the user to choose to see the (colorized) word-based diff when they want one. I now see that the config file approach in my proposed patch doesn't go close enough to that to be worth considering further.

I think a proper implementation of the above command would have to
* add something to builtin_add_options in builtin/add.c,
* set a new static variable in add.c, and
* extend the calling logic for interactive_add() and/or
run_add_interactive() accordingly,
so that the perl script can get the user's choice on the command line
and not from a config file. And only respond when colorization is
configured.

Does --patch=color, --interactive=color or adding new option --color-words make more sense?

I'll have a think about that and get back to you guys.
Thanks!
Mark
> -Peff
Previous: Jeff KingNext: Jeff King
Message 4 of 5 in “Re: [PATCH] git-add--interactive.perl: Permit word-based diff”
  1. Jeff KingJun 18, 2013
  2. Thomas RastJun 18, 2013
  3. Jeff KingJun 18, 2013
  4. Mark AbrahamJun 18, 2013
  5. Jeff KingJun 18, 2013

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.