bugGNU patch - Bugs: bug #33065, Allow idempotent patching

 
 

bug #33065: Allow idempotent patching

Submitter:  Philip Prindeville <pprindeville>
Submitted:  Wed 13 Apr 2011 04:54:02 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 08 Aug 2016 11:59:33 AM UTC, comment #5: 

Really, the only thing patch can tell you is if a patch can be reverse applied.  From that you may want to assume that the patch was already applied, but there is no guarantee: there are cases where the same patch can be reverse as well as forward applied.  There is no such thing as idempotent patching as long as the patch doesn't contain both files in their entirety (i.e., with infinite context).

Andreas Gruenbacher <agruen>
Group administrator
Mon 08 Aug 2016 11:25:23 AM UTC, comment #4: 

I'd strongly recommend to reconsider this issue.

Idempotent patching would be really appreciated in my use cases.


Consider the following, I'm building a specific software for all released versions. Since version 3 and on a specific feature was added.

If now one wants to build all software versions (also 1 and 2) with that features, applying the patch to them would work out. For version 1 and 2 it would apply cleanly, but for 3 and on it would be ignored as it was already applied.

"already applied" is a very different outcome in this case than "patch didn't cleanly apply".

Domen Kožar <ielectric>
Thu 03 Jan 2013 09:27:20 PM UTC, comment #3: 

The description of the --forward option in the man page isn't very clear.  Here is a better version:

  When a patch does not apply, patch usually checks if the patch
  looks like it has been reversed.  The --forward option prevents
  that.

Patch doesn't ignore (or "silently apply") patches like three-way merge usually does.  The result wouldn't be reliable enough with the information available.  If you insist on ignoring patches that look like they have already been applied, do so by checking if they can be reverse applied.

Andreas Gruenbacher <agruen>
Group administrator
Thu 03 Jan 2013 11:03:33 AM UTC, comment #2: 

Consider the following in bash:
$patch -s --forward -i mypatch.txt myfile.txt
$echo $?
0
$patch -s --forward -i mypatch.txt myfile.txt
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file myfile.txt.rej
$echo $?
1

(i.e. patching one file twice with the same patch)

If I read the manual page correctly, '-s --forward' should silently apply a forward patch, and just drop it if applied already. It does this, but prints a warning and returns non-zero, which is not what one wants when writing shell scripts.

This was tried with patch v. 2.6.1

Kalle Raiskila <kraiskil>
Wed 13 Apr 2011 06:17:14 PM UTC, comment #1: 

I am not sure what you mean.  A patch that has already been applied can be reverse applied, which reverts it.  (This may fail if the patch modifies the same file more than once though.)

Also note that patch uses a heuristic to determine if a patch has already been applied, and that this heuristic can fail.  Trying to revert the patch with --reverse --dry-run is safer.  This can also fail if a patch file modifies the same file more than once though.

Andreas Gruenbacher <agruen>
Group administrator
Wed 13 Apr 2011 04:54:02 PM UTC, original submission:  

Software projects building their own patched kernel are often the source of kernel fixes.  This patches will appear in the project tree and be submitted upstream, eventually appearing in kernel releases.

This creates scenarios where a patch might be attempted on a kernel release that's already been applied.

The --forward flag enables two separate and orthogonal conditions: already applied patches and reversed patches.

Separate options are needed to control reversed and already applied patches.  The --forward option partially overlaps with --reverse.

I'm proposing an option called --idempotent that allows already applied patches to be quietly ignored.

Philip Prindeville <pprindeville>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ielectric (Posted a comment)
  • -email is unavailable- added by kraiskil (Posted a comment)
  • -email is unavailable- added by agruen (Posted a comment)
  • -email is unavailable- added by pprindeville (Submitted the item)
  • -email is unavailable- added by pprindeville
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-01-03 agruen StatusNeed Info Wont Fix
        Open/ClosedOpen Closed
    2011-04-13 agruen StatusNone Need Info
    2011-04-13 pprindeville Carbon-Copy- Added pprindeville

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code