On Sun, Jan 12, 2020 at 05:04:07AM +0100, Andreas Grünbacher wrote: > Hi Vladimir, > > Am Sa., 11. Jan. 2020 um 16:19 Uhr schrieb Vladimir D. Seleznev > <vsele...@altlinux.org>: > > The following patches implement strip value guessing option for GNU Patch. > > Please take a look at them. > > > > The idea is simple: it looks for the longest existent pathname to patch, and > > if it finds one, then it tries to patch the file. > > > > If the patches are deemed fine to be accepted, I'm ready to proceed with the > > copyright assignment. > > In general, this rather seems like an option not to use. But let's see > if the idea can be salvaged. > > When the first patch in the input creates a file in a sub-directory > (or removes a file and is applied in reverse), the guess will fail if > that sub-directory doesn't exist: > > --- /dev/null > +++ a/dir/foo > @@ -0,0 +1 @@ > +foo > > I guess it would make sense for patch to refuse guessing in that case?
I agree. Now it just create file in the current directory. I'll fix that. But there are two possible option to handle this: either to refuse any patches that started with patching /dev/null, or to refuse when there is no any of sub-directory in the patching directory that is listed in the path of the file that is supposed to be created. I guess the second option should be used. Anyway the following patch (almost) always will be refused: --- /dev/null +++ a/foo @@ -0,0 +1 @@ +foo > What should happen when patch finds multiple of the names in the patch > (pch_name)? Should the minimum strip level be used? I think it should, and it is how it is the current implementation I've sent. I can provide a rationalization for it. Usually patch is made as diff between original and changed top directories of project. It is fair for old style patch made (like diff -ru proj.org proj > proj.diff), and for patches generated from some CVS as well (e.g. git diff, git format-patch, etc). These patches are applied to the top directory of the project, that means that the minimum strip level should be used. > How does this interact with -R guessing as with the following patch > (apply in an empty directory with -p0)? > > --- /dev/null > +++ bar > @@ -1 +0,0 @@ > -bar It works. $ ls -l total 0 $ cat ../bar.patch --- /dev/null +++ bar @@ -1 +0,0 @@ -bar $ /usr/src/tmp/patch-buildroot/usr/bin/patch -pg -R < ../bar.patch patching file bar $ ls bar $ cat bar bar > The "/dev/null" patch doesn't make sense to me. Sorry, I didn't understand this point. > If we want this kind of guessing, we should document how it works and > when it doesn't. I agree. And as I see this should be documented in the manpage, right? Should it be like following text? With this option it tries to use as smallest strip level as possible to patch an existent file. If several files are present in the patch, the same value for strip level is used: the value that was get for the first file to patch. When the first patch in the input is about to create file, it will be refused if none of sub-directory listed in the path is present in patching directory. > This needs to become a new long option; we can't cram it into -p. Ok. If this option will be named `--autoguess-strip' will it be OK? Can `-pg' option remain as well? -- WBR, Vladimir D. Seleznev
