Hi, On Mon, 19 Feb 2007, Junio C Hamano wrote: > 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. That is important to keep in mind for the following: > > 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. BTW this is what I argued, too. But I am not hard minded. > > 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. But not all patches are generated by git. Unfortunately. > > 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). > > 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... ... and here we come back to the argument that git-apply is so much saner than patch. And yes, it happened to me a while ago that I used "patch", cursed for a little moment, said "git reset --hard" and cursed even more when I realized that I was not in a git-tracked working directory! My vote is for "take the current subdirectory as root for the patch", since that is what I'd expect out of the box. But as I said: I am not _that_ hard minded, at least on this issue. Ciao, Dscho - 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