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

[Egbert Eich]

Hi Jean!

Jean Delvare writes:
 > Hi Andreas, Egbert,
 > 
 > A bug was reported when using "quilt new -p ab". Option "-p ab" gets
 > stored in the series file, however other quilt commands aren't ready to
 > deal with this. "quilt push" will pass "-p ab" straight to patch(1)
 > which doesn't support it. Also "quilt refresh" will not preserve the

When passing it manually one just has to remember to replace it by '-p1'.

 > option in the series file. The latter issue was reported here, with a
 > candidate fix:
 > 
 > https://savannah.nongnu.org/patch/index.php?10094
 > 
 > 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'.

 > 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.

 > 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 ;)

Cheers,
        Egbert.