From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 29009 invoked from network); 29 Sep 2022 05:49:51 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 29 Sep 2022 05:49:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received: from mail-pg1-f181.google.com ([209.85.215.181]) by 9front; Thu Sep 29 01:48:02 -0400 2022 Received: by mail-pg1-f181.google.com with SMTP id u69so548408pgd.2 for <9front@9front.org>; Wed, 28 Sep 2022 22:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney.org; s=google; h=subject:to:from:date:message-id:from:to:cc:subject:date; bh=oGiq3xz1tzVctv7hCvvfbxfKr+ZveZ8R5aPqW80xU1Y=; b=WS1bRvaa5s+jbOeMdrlAHtT6vrAkHnZYhUu8j9iTfAGJ3hvjmbiKb2Y/kpdQqsbaJK VJcGVeg0EIhPpbqwO1L0x/WMTJaDyxwyTjatq5OxVOrA9zCS174RcUr9lfoZ2uWJ6mSn hq1QwAfwngjwQoYb6CPPAkZpucWBpqlnZx4jtcEZA97ozWmnyuPBaWXiPt/Lf/eP23sj UObvKjA6UyzNkUJmzK1rlqPNnXAanaLuuYNJ4n6vVs2Cop7RxMyzcddUlDk+y566AH3+ pkuCBEavjDH2fvoDC5MfyuKwPUbu5PGmY76SWRDYbL9/IXNI6x90Q5Etlopiq7gpuGCv vSog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=subject:to:from:date:message-id:x-gm-message-state:from:to:cc :subject:date; bh=oGiq3xz1tzVctv7hCvvfbxfKr+ZveZ8R5aPqW80xU1Y=; b=sJT5/aFGzcJ5wtVq96jRxw0FmwGNLxOfMwIQvbTU7p9MfdHTxHRsRzz/eFHv7Abr+f x5my13u5S9hxhhdJD77gxVs8RpbwdIC/M9mVd3FFvTCXF9dKPnoeRoUvYppHlKX7kMEO ZkFG5yi49RqoqA/8NX8M44aV7gpUk+LJC+8Tr2/tIQXb2hY1yppPuWPLRdIOnR4smgqY XEIYHRWf4n5kHSd9eibHjZfbNxkPEmTu98mJeOE3P1OPGV3v7PYoCoKwP9ix1DWyIgWK aaanK2mtq8sbBnjipHiqwTBHPd49stn5s4WRrEo09RJWGnSNYX4l8WMSpour7xcJrSwQ KRSQ== X-Gm-Message-State: ACrzQf3mQoL1/PNv367jdTg57YarXhi4bSWsP1FSqCONtu4dlaDFkMIB VPLt7Smi27MWA8Axvj5Jb4C/FdbXhspK8NXO X-Google-Smtp-Source: AMsMyM5nZY76KrDInTA2QvywvZfuQ1mT+cIDft8NsyrsLbm4NbYbuSr6XdKIpneTGqqnI/ALgMU8nw== X-Received: by 2002:a05:6a00:1a55:b0:557:b7a3:6738 with SMTP id h21-20020a056a001a5500b00557b7a36738mr1514709pfv.61.1664430477803; Wed, 28 Sep 2022 22:47:57 -0700 (PDT) Return-Path: Received: from localhost (104-49-27-101.lightspeed.sntcca.sbcglobal.net. [104.49.27.101]) by smtp.gmail.com with ESMTPSA id n15-20020a170902d2cf00b0016dc78d0153sm4884502plc.296.2022.09.28.22.47.56 for <9front@9front.org> (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 28 Sep 2022 22:47:57 -0700 (PDT) Message-ID: <6335318d.170a0220.77fb0.8d3c@mx.google.com> Date: Wed, 28 Sep 2022 22:49:37 -0700 From: Michael Forney To: 9front@9front.org List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: transactional cloud CSS optimizer Subject: [9front] patch(1) filename detection Reply-To: 9front@9front.org Precedence: bulk I recently encountered an issue using patch and git. Say I remove two files in git and generate a patch: diff 0890cdaa2d2a6ad756ba98130e078b3cd64bee7d 5b6279eb53ece69d2a014adf566f22adb61d94e4 --- a/a +++ /dev/null @@ -1,1 +1,0 @@ -foo --- a/b +++ /dev/null @@ -1,1 +1,0 @@ -bar When I try to apply this, we process the first hunk. curfile is nil, so we set it to /dev/null, then read the contents of a into f, and apply the hunk. Then, we get to the second hunk. It also has newpath of /dev/null, so we *do not* read the contents of b. However, now we are searching for the contents of b in a, which fails: stdin:8: unable to find hunk offset in b Historically, I believe patch implementations worked by using the first file that existed of the --- name and the +++ name, falling back to prompting the user for the name of the file to patch. The new 9front patch works a bit differently and patches the --- name into the +++ name, with a bit of logic to remove files with /dev/null as the +++ name. I don't think this is ideal behavior, because it is common to see patches like --- a.orig Wed Sep 28 21:53:55 2022 +++ a Wed Sep 28 21:53:58 2022 @@ -1 +1 @@ -foo +bar for example in BSD ports systems. Given this file, patch(1) will complain patch: open a.orig: 'a.orig' file not found rather than patching the file a. Similarly, given a patch like --- a +++ a.new @@ -1,1 +1,1 @@ -foo +bar patch(1) will write the patched file to a.new and leave a alone rather than patching a. I propose we implement the standard behavior in patch(1) (maybe without the prompting part) to interoperate better with patches created by other tools. This will fix the issue I encountered since there is no separate "old path" and "new path", just the file selected for patching. We can still retain the logic to remove the file if the +++ name is /dev/null. However, longer term it might be worth supporting the git-diff extended header lines: deleted file mode new file mode old mode new mode There are also headers for renames and copies, but I don't think git or patch should bother with that, and should just present them as deleted and added files. Thoughts?