bug-patch
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoguessing patch strip


From: Vladimir D. Seleznev
Subject: Re: Autoguessing patch strip
Date: Tue, 14 Jan 2020 13:26:51 +0300
User-agent: Mutt/1.10.1 (2018-07-13)

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
> <address@hidden>:
> > 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]