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 15, 2008, 15:53 UTC
Message-ID
<alpine.LFD.1.10.0808150843320.3324@nehalem.linux-foundation.org>
In-Reply-To
<20080814202159.GD7138@leksak.fem-net>
On Thu, 14 Aug 2008, Stephan Beyer wrote:
Show 5 quoted lines
> 
> What I missed when I first used git-apply (git-am) with some not-so-
> well-done patches was something like a "simulated merge" (of course,
> only when you ask for it), i.e. something like a user-friendly
> --reject behavior:

It's really hard to do. Largely impossible, I think. The reason is that when a patch fails, you - by definition - don't really know where it is supposed to apply and what the original code is. Because if you did, the patch wouldn't fail!

Git *can* do it (git am -3, as people have said), when you have a git patch, and the patch indicates the original blob. Then git can just see what the original state was, reconstruct the patched file, and do a normal three-way merge. But it's not doable in general.

Now, we could do other things, like try to _search_ for an original blob that it applies cleanly to (or even have a "guessing mode" that does a really rough patch-application with the GNU patch defaults and then does a three-way merge of a fudged version with no fuzz as the base), so I'm not saying that it would be fundamentally impossible to try to go further than what we do now, but it's definitely not trivial to do.

Show 5 quoted lines
> Instead of generating reject files it puts conflict markers into the file.
> (If no context matches at all, then perhaps just insert them at the lines
> that the hunk header says.)
> And then declaring the files as "unmerged", so that you can see it in
> git status.

I do agree that it would be very cool. I'm so used to editing patches to match the target files by hand that I don't personally mind. I absolutely detest reject files personally because of the way they mean that you have a half-way done thing, so I will literally always edit the original patch in place instead.

But I agree that what you describe would be absolutely lovely.
			Linus
Previous: Jeff KingNext: Francis Moreau
Message 13 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.