Re: [Quilt-dev] quilt new -p ab

[Jean Delvare]

Hi Egbert,

On Mon, 30 Aug 2021 14:26:23 +0200, Egbert Eich wrote:
> Jean Delvare writes:
>  > This all originates from this 12-year-old commit:
>  > 
>  > commit 66f9da46333e3d268cd1dd429ff2d2a674450d80
>  > Author: Andreas Gruenbacher
>  > Date:   Wed Nov 25 18:38:10 2009 +0100
>  > 
>  >     - new command: Add -p ... option (equivalent to diff -p ...).
>  >       (Based on a patch from Egbert Eich.)
>  > 
>  > Apparently this was only ever tested with "-p0" and not with "-p ab"?  
> 
> This is not unlikely. When I sent these patches to Andreas, I was
> addressing issues I had with RPM packages, and RPMs do not support
> the -p ab option with %patch. So I may have never looked into '-p ab'.

That was my guess, thanks for confirming.

>  > This brings the question as to whether we actually want to support
>  > option "-p ab" in the "new" command and in the series file.
>  > 
>  > My initial feeling is that we shouldn't, as the options in the series
>  > file are meant to be passed to patch(1), so we should only store "-p0"
>  > and "-R" there. Thus one way to fix the bugs is to simply remove the
>  > support of "-p ab" from the "new" command.  
> 
> I believe my intention was to support also 'higher' levels than 0 or 1.
> 'diff' also supports -p ab - at least according to the man page.

Hmm? -p means something completely different for diff (--show-c-function).

>  > On the other hand, supporting "-p ab" in the series file would allow
>  > preserving the patch format automatically at a per-patch level (as
>  > opposed to QUILT_REFRESH_ARGS="-p ab" which enforces it for all
>  > patches). Which is something we already do for "-p0".
>  > 
>  > So I see one good reason to go in each direction, but we need to decide
>  > which direction to take. Thoughts?  
> 
> The behavior should be consistent. When dropping it, it should probably
> be dropped everywhere. On the other hand, this might make people unhappy
> whose workflows will break.
> That someone has bothered to provide a fix shows that this feature has
> a user ;)

Sometimes people fix something that is broken (and has been broken for
long because it had no user) simply because they do not realize that
they can achieve the same (or sometimes even better) in a different
way, that already works. That's what I would like to avoid here.

Of course if adding support solves an actual problem and can be done
easily then I'll do that.

Thanks,
-- 
Jean Delvare
SUSE L3 Support