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

Re: git diff: add option for omitting the contents of deletes

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Feb 28, 2011, 07:31 UTC
Message-ID
<4D6B4F6B.1040209@drmicha.warpmail.net>
In-Reply-To
<7v39n9uldp.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 28.02.2011 00:07:
Show 15 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> Wasn't the pager invented for sifting through output which has to be
>>> several pages, but not not for that which could be more concise? ;)
>>>
>>> In fact, -D would be quite analogous to -M and -C in that respect.
>>
>> There is a big difference: -M and -C lets your recipient reproduce the
>> state using the change you are trying to convey with the diff output in
>> either direction (iow, "apply -R" works), but your "-D" would not have
>> that property.
> 
> Having said that we have always valued "reversibility" and a casual -D is
I didn't know, but I guess I haven't come across those issues yet.
Show 6 quoted lines
> not in line with that principle, I don't have a strong objection if the
> new mode of operation is marked clearly as "nonusable if you are trying to
> produce appliable diff (iow, don't send such a patch to mailing list--it
> is for viewing purposes only)", treating it just like the --color-words
> and the --stat options (there isn't even need to mark these as unusable
> for that purpose, as people with common sense would be able to guess).

Yes, it is purely intended as "for viewing by humans". Even in the forward direction saying "delete that path" is different from saying "delete that content from that path", i.e. "diff -D" output may apply without conflicts in cases where "diff" output does not.

That aspect is similar to -M and -C, though - unless we check the sha1 of the blobs before applying the patch (which would be possible for -D also) - do we?

Show 6 quoted lines
> If we were to do this, it probably is a good idea to apply that for a
> typechange patch (the one that is produced when a symlink turns into a
> regular file and vice versa) as well.  It also might make sense to apply
> the similar principle to shorten the output with -B when a rewrite patch
> is expressed as a single hunk patch that removes everything old and then
> adds everthing new.

Reminds me of my failed attempt to make the diff output for symlinks more human-friendly. The latter can be solved with textconv, though.

Michael
Previous: Junio C HamanoNext: Jeff King
Message 9 of 32 in “git diff: add option for omitting the contents of deletes”
  1. Mart SõmermaaFeb 26, 2011
  2. Junio C HamanoFeb 26, 2011
  3. Michael J GruberFeb 27, 2011
  4. Mart SõmermaaFeb 27, 2011
  5. Michael J GruberFeb 28, 2011
  6. Mart SõmermaaFeb 28, 2011
  7. Junio C HamanoFeb 27, 2011
  8. Junio C HamanoFeb 27, 2011
  9. Michael J GruberFeb 28, 2011
  10. Jeff KingFeb 28, 2011
  11. Jeff KingFeb 28, 2011
  12. Michael J GruberFeb 28, 2011
  13. Jeff KingFeb 28, 2011
  14. Michael J GruberFeb 28, 2011
  15. Jeff KingFeb 28, 2011
  16. Junio C HamanoFeb 28, 2011
  17. Jeff KingFeb 28, 2011
  18. Junio C HamanoFeb 28, 2011
  19. Junio C HamanoMar 1, 2011
  20. Mart SõmermaaMar 7, 2011
  21. Michael J GruberMar 8, 2011
  22. Junio C HamanoMar 8, 2011
  23. Mart SõmermaaMar 8, 2011
  24. Jeff KingMar 8, 2011
  25. symling diff driver (Was: Re: git diff: add option for omitting the contents of deletes)Michael J Gruber, Feb 28, 2011
  26. Jeff KingFeb 28, 2011
  27. attr: make attributes depend on file typeMichael J Gruber, Feb 28, 2011
  28. Jeff KingFeb 28, 2011
  29. Junio C HamanoFeb 28, 2011
  30. Michael J GruberMar 1, 2011
  31. Mart SõmermaaFeb 28, 2011
  32. Michael J GruberFeb 28, 2011

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.