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

Re: Why doesn't git-apply remove empty file

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Aug 14, 2008, 19:57 UTC
Message-ID
<alpine.LFD.1.10.0808141246190.3324@nehalem.linux-foundation.org>
In-Reply-To
<38b2ab8a0808141242k4bd6867dt8ef54f160713061f@mail.gmail.com>
On Thu, 14 Aug 2008, Francis Moreau wrote:
Show 9 quoted lines
> 
> Well patch(1) is so used out there that makes git-apply often do the
> wrong thing for such corner cases when applying a patch made by
> patch(1).
> 
> Maybe git-apply would be more friendly regarding patch(1) if it has an
> option to emulate GNU patch for some situations. Or if this means
> adding too many quirks in git-apply code, maybe give the possibity for
> git-am to use patch(1) instead of git-apply.
The thing is, "patch" is a total piece of utterly unbelievable SH*T.

git-apply acts differently, yes, but it acts differently for a damn good reason. No, you cannot replace git-apply with that horrible crap that is GNU patch.

Some of the reasons are purely trivial implementation issues:
 - git-apply knows about the index, and knows about updating it properly, 
   including tracking new files automatically.
That's an important thing, but yeah, it's an implementation issue.
The other things that git-apply do right are much more fundamental:
 - git apply doesn't leave half-applied state turds around when a patch 
   fails.
   People who actually use "patch" for large projects will know the pain 
   here: if a diff fails in the middle, GNU patch will have applied the 
   previous parts (including to other files), and it's now your problem to 
   fix it up. There's no way to do an all-or-nothing patch, which is often 
   a huge requirement.
 - git apply doesn't guess (unless you really tell it to, and even then it 
   will guess a whole lot less than GNU patch). If a "git apply" succeeds, 
   it was probably good. If a GNU patch invocation succeeds, it might have 
   been total and utter crap, but hey, it tried to apply that piece of 
   shit very aggressively even when it made no sense and the context 
   didn't actually match even _remotely_.
   Yeah, context diffs can still mis-apply even with git apply, but they 
   do so a hell of a lot less than with GNU patch, and if you want it to 
   just generate a random end result, you at least have to _ask_ for it.
So no. There's no way in hell that git am should use GNU patch.
But as mentioned, if somebody wants to parse the dates, we could do that. 
			Linus
Previous: Francis MoreauNext: Linus Torvalds
Message 7 of 14 in “Why doesn't git-apply remove empty file”
  1. Francis MoreauAug 12, 2008
  2. Junio C HamanoAug 13, 2008
  3. Francis MoreauAug 13, 2008
  4. René ScharfeAug 13, 2008
  5. Linus TorvaldsAug 13, 2008
  6. Francis MoreauAug 14, 2008
  7. Linus TorvaldsAug 14, 2008
  8. Linus TorvaldsAug 14, 2008
  9. Stephan BeyerAug 14, 2008
  10. Jeff KingAug 14, 2008
  11. Stephan BeyerAug 14, 2008
  12. Jeff KingAug 15, 2008
  13. Linus TorvaldsAug 15, 2008
  14. Francis MoreauAug 14, 2008

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.