Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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). Yup. > 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. Hmm. I am puzzled. Are you suggesting to change behaviour of "git apply" with --index? git generated patch, or patches on the kernel list that are not generated with git are always relative to the top-level, so I think the current --index behaviour makes tons of sense. > 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? I think it boils down to this question: when you have a patch on hand that you are considering to apply to your tree, if the patch talks about just "Makefile" (e.g. it says "a/Makefile b/Makefile") which Makefile is more likely to be what the patch is talking about -- the toplevel one or the one in the subdirectory you happen to be in? Both (1) diff generated by git are always relative to top, and (2) the BCP on the kernel list (and I suspect many other projects are run this way as well) is to have diff relative to the toplevel, suggests that "a/Makefile b/Makefile" patch is much more likely to be about the top-level Makefile no matter where you happen to be. Although the fact you *are* in the subdirectory when you are considering that patch makes it a bit more plausible than otherwise that the patch may be about sub/directory/Makefile, I do not think that is strong enough hint to make it more plausible to apply to the sub/directory one than to the toplevel. If the patch were what you made by running "GNU diff" inside a corresponding subdirectory of another repository (perhaps you wanted to feed uncommitted changes from there to this repository), then you can always use "GNU patch" to apply. If you made such a one-shot patch using git-diff, it will tell you the correct directory to apply to, so... - 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