On Mon, 19 Feb 2007, Junio C Hamano wrote: > > ... > > 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. One thing I forgot to mention: "git apply" doesn't apply *anything* unless everything applies cleanly. In contrast, when "patch" fails in the middle, it will have done part of the job, and then leaves a reject file. I much prefer the "everything or nothing" approach of git-apply (again, obviously with "--reject" you can make it work the bad old way too). > 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. Ahh.. I'm not going to veto it, although I have to admit that I don't know what the "right answer" is, or if a "right answer" really exists. I _think_ that the right answer is to (a) yes, make it be consistent, but (b) _not_ make it be the way we do "--index" now. Right now, when we see "--index", we do the "setup_git_directory()" and the git_config() stuff - which is (I think) something we should always do, but then we do *not* prefix the patch itself with the prefix we got. And I think that's wrong. I think we should always do the "-p1" behaviour from where we started. Then, if somebody is in a sub/directory/, maybe they need to add a "-p3" to indicate that, but at least that's better than having a patch that just says "Makefile", and applying the patch to the *wrong* "Makefile" (top-level one, rather than the one you were in). Hmm? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html