Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config

From: Junio C Hamano <junkio@cox.net>
Date: Feb 19, 2007, 23:14 UTC
Message-ID: <7vodnp68p8.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0702191450580.20368@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 7 quoted lines

> 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:
> ...
> 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).

All true.

> 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.

I've seen a few on git list and I think I saw a couple on kernel list as well in the past.

By the way, do you want to veto a related change that makes git-apply behave consistently between:

	$ cd sub/directory
        $ git apply patch.file

and

	$ cd sub/directory
        $ git apply --index patch.file

The issue is, that "patch.file" (typically) starts with:

	diff a/sub/directory/Makefile b/sub/directory/Makefile
	--- a/sub/directory/Makefile
	+++ b/sub/directory/Makefile

and the form without --index would say "What are you talking about? I do not see sub/directory/Makefile".

I consider this is a bugfix, but it does change the behaviour, so I am a bit worried about possible fallout.