From: Linus Torvalds <torvalds@linux-foundation.org>
To: Francis Moreau <francis.moro@gmail.com>
Cc: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
"Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: Why doesn't git-apply remove empty file
Date: Thu, 14 Aug 2008 12:57:09 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0808141246190.3324@nehalem.linux-foundation.org> (raw)
In-Reply-To: <38b2ab8a0808141242k4bd6867dt8ef54f160713061f@mail.gmail.com>
On Thu, 14 Aug 2008, Francis Moreau wrote:
>
> 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
next prev parent reply other threads:[~2008-08-14 19:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-12 16:17 Why doesn't git-apply remove empty file Francis Moreau
2008-08-13 0:25 ` Junio C Hamano
2008-08-13 7:48 ` Francis Moreau
2008-08-13 21:52 ` René Scharfe
2008-08-13 23:09 ` Linus Torvalds
2008-08-14 19:42 ` Francis Moreau
2008-08-14 19:57 ` Linus Torvalds [this message]
2008-08-14 20:02 ` Linus Torvalds
2008-08-14 20:21 ` Stephan Beyer
2008-08-14 20:54 ` Jeff King
2008-08-14 21:10 ` Stephan Beyer
2008-08-15 4:08 ` Jeff King
2008-08-15 15:53 ` Linus Torvalds
2008-08-14 20:17 ` Francis Moreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.1.10.0808141246190.3324@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=francis.moro@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rene.scharfe@lsrfire.ath.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).