[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-patch] How to handle read-only trees

From: Andreas Grünbacher
Subject: Re: [bug-patch] How to handle read-only trees
Date: Fri, 10 Mar 2017 16:45:35 +0100

2017-03-10 12:16 GMT+01:00 Jean Delvare <address@hidden>:
> 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?

The fact that quilt uses patch in a very particular way doesn't
actually create a connection between --backup and --read-only; those
two options serve entirely different purposes.

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

I can follow the argument that files should be (owner) writable after
patch has modified them. But again I don't see the connection with

A corner case with quilt is when a patch tries to modify a file but
doesn't actually end up changing anything. In that case, patch should
probably still create a backup and make the original file writable, if
only to make life easier for quilt.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]