Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Feb 19, 2007, 22:57 UTC
- Message-ID
- <Pine.LNX.4.64.0702191450580.20368@woody.linux-foundation.org>
- In-Reply-To
- <20070217233203.GA6014@coredump.intra.peff.net>
On Sat, 17 Feb 2007, Jeff King wrote:
Show 8 quoted lines
> > On Sat, Feb 17, 2007 at 03:31:18PM -0800, Junio C Hamano wrote: > > > I thought about that, but decided against it. If you are truly > > operating outside a git managed repository, it does not feel > > right to apply configuration user has for git. > > Then why are they using git-apply, and not patch?
I don't know about others, but I use "git apply" even outside git (*) simply because the defaults for it are a lot better than "patch".
I've always hated how patch has some _really_ unsafe default behaviour:
- it will guess at filenames. As in *totally* guess. If you have a patch that touches a Makefile in a subdirectory, but that subdirectory had been renamed or removed, it's entirely possible that "patch" will actually find *another* file called "Makefile" (most likely your top-most one) and apply the patch to that.
And yes, this has actually happened to me.
- it defaults to various unsafe options, like allowing a big fuzz factor (I think it defaults to --fuzz=2), which means that if you've already applied the patch, but there was _another_ place that looks a bit like the original place, "patch" will happily apply it *again* because the default fuzz-factor is so permissive.
git-apply has much saner defaults (it defaults to something pretty safe, and you can then make it less safe if the patch doesn't apply).
It also knows about renames. I hope that some day people will start sending rename-patches around, just because they are *so* much more readable than delete/create patches.
Linus
(*) Although I have also noticed that even more often than using "git apply" outside a git thing, I just import everything into git these days. So I may not have actually used git-apply outside of a git project in a long time any more. But I did, a few times.