[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-patch] Time for a new release?
From: |
Jean Delvare |
Subject: |
Re: [bug-patch] Time for a new release? |
Date: |
Mon, 16 Apr 2012 19:21:41 +0200 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32.54-0.3-pae; KDE/4.3.5; i686; ; ) |
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
- Re: [bug-patch] Time for a new release?, (continued)
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/06
- Re: [bug-patch] Time for a new release?, Jean Delvare, 2012/04/10
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/12
- Re: [bug-patch] Time for a new release?, Mike Frysinger, 2012/04/12
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/12
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/13
- Re: [bug-patch] Time for a new release?, Mike Frysinger, 2012/04/13
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/14
- Re: [bug-patch] Time for a new release?, Jean Delvare, 2012/04/16
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/16
- Re: [bug-patch] Time for a new release?,
Jean Delvare <=
- Re: [bug-patch] Time for a new release?, Andreas Gruenbacher, 2012/04/17
- Re: [bug-patch] Time for a new release?, Jean Delvare, 2012/04/13