Re: [bug-patch] Time for a new release?

[Jean Delvare]

Hi Andreas,

On Monday 16 April 2012 06:08:42 pm Andreas Grünbacher wrote:
> Jean,
> 
> Am 16. April 2012 15:35 schrieb Jean Delvare <address@hidden>:
> > So with the latest version of GNU patch, every "quilt push" results
> > in a warning about read-only files. This is rather inconvenient and
> > passing --quiet doesn't even make it go away. And "quilt push -f"
> > fails. Bad.
> 
> Why does "quilt push -f" fail?

This is somewhat unintuitive (I had to check the code twice myself) but 
"quilt push" calls "patch -f" while "push -f" calls "patch" (no -f). And 
new version of "patch" fails on read-only files unless forced, so now 
"quilt push -f" fails on read-only files.

Maybe we could use "patch -f" always, I'm not sure. But even then, 
"patch" now displays a warning message, which can't be suppressed, so it 
won't completely help.

> > I do agree that the previous behavior (silently operating on
> > read-only files by default) was wrong, but I think the new behavior
> > is wrong too. If I tell patch to operate on a read-only file with
> > --backup option (as quilt does), it would seem that I know what I'm
> > doing. So I think patching read-only files should be as silent and
> > successful as it used to be as long as --backup option is used.
> 
> I really can't follow you here. Patch should behave consistently on
> read-only files, whether or not it creates backups.

Maybe this is twisted thinking from me, but I think --backup changes the 
semantics of what patch is doing, especially for read-only files. 
Without --backup, patch operates in-place on the file, so it changes it, 
which is not acceptable if the file is read-only. But with --backup, the 
original file is preserved, which complies with its read-only status, 
and I see the modified file as a new file (which may even not be read-
only, that wouldn't shock me.)

> > [...] we don't want to make files writable before they are unlinked
> > from the reference tree
> 
> A "cp --reflink" copy would work, but that is not widely supported
>  yet.

It's not even supported on my own system. The whole concept is news to 
me. How does it work, hard link + extended file attribute which says 
"break the link on file change"? Can this mode be set afterwards?

>  Maybe we do need to let the user choose between the old and new
>  behaviour.

If you don't like my proposal to depend on --backup, then yes, I presume 
this is the way to go, although I'm not quite sure what this new option 
should be named.

Thanks,
-- 
Jean Delvare
Suse L3