Hi all, Where I work, we use GNU patch to work on read-only source trees. The reason is that we work with hard-linked trees, and apply different patch series to the different copies. We want to make sure nobody accidentally affects another tree by changing a file without first breaking the hard link.
While it works somewhat, there are still 2 issues left that I'd like to solve. 1* Since April 2012 (commit 9a26fde226), patch complains when patched files are read-only. That's a lot better than failing, as was the case between May 2010 (commit cabd1add57) and April 2012 (thanks Andreas for fixing that!) but still not too convenient. I know that users can pass option --read-only=ignore to get rid of the warning, but this option is not supported on older versions of GNU patch, and our users may have to work on older systems sometimes, so they have to change their habits depending on the system they are working on. More importantly, I believe it is conceptually wrong to complain about patching a read-only file if the user also asks for the original file to be backed up (which we always do.) If you keep a backup of the original read-only file, then modifying a copy of that file is not breaking the read-only paradigm. So I would like to propose that option --read-only defaults to "ignore" if --backup is passed, and to "warn" if not (as is the case today.) What do you think? 2* After patching a read-only file, and even if --backup and --read- only=ignore are passed, the patched file is still read-only. This means that our users must manually chmod +w each patched file to which they need to make further changes. It seems conceptually wrong to me, as option --backup created a new copy of the file and patched it, the contents are already modified so the read-only nature of the file is already gone in practice. So I would like to propose that patched files are always made writable when option --backup is used. What do you think? Thanks, -- Jean Delvare SUSE L3 Support