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
Jeff King <peff@peff.net>
Date
Feb 28, 2011, 12:59 UTC
Message-ID
<20110228125909.GA9054@sigill.intra.peff.net>
In-Reply-To
<4D6B95E3.7040603@drmicha.warpmail.net>
On Mon, Feb 28, 2011 at 01:32:35PM +0100, Michael J Gruber wrote:
Show 21 quoted lines
> > Actually, thinking on this a bit more, I guess "-M" and "-C" are usable
> > without the sha1. In fact, we don't even provide it for a strict 100%
> > rename, and for a rename-with-patch, you can apply the patch, assuming
> > you have the original file in any form. So they are really about "is
> > your recipient using git", not "is your recipient using git _and_ will
> > he/she have the right sha1".
> 
> $ git mv Makefile Dofile
> $ git staged # yadayada
> diff --git c/Makefile i/Dofile
> similarity index 100%
> rename from Makefile
> rename to Dofile
> 
> Same with copy.
> 
> But that's not good, is it? I mean, Alice sends me her "copy patch" and
> I send her my Makefile patch, both on top of the same base. We both
> apply each other's patch cleanly. We end up with different "Dofile".
> Checking the sha1 would prevent this. It's no surprise that patch
> application is non-commutative, but shouldn't we catch this?

Won't you either get a conflict or end up with the same Dofile? Clearly you will have a Dofile with your Makefile changes, as you applied the movement on top of your changes.

Alice will either:
  1. Apply not using rename detection (e.g., not using git, or using
     "git am" without "-3"). In this case, she gets a conflict because
     she no longer has Makefile.
  2. Apply using rename detection (e.g., via "git am -3"). In this case,
     we will notice the movement of Makefile to Dofile, and apply the
     patch to Dofile.

Still, I do wonder if we should be including an index line on a straight rename patch. It lets the recipient check that what is being renamed is what they have (IOW, it gives the same check that they would do if they ahd the whole patch text). And then the recipient can decide how to resolve the conflict.

-Peff
Previous: Michael J GruberNext: Michael J Gruber
Message 13 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.