Hi Jason, On Wed, 7 Jan 2015 11:39:12 -0600, Jason Wessel wrote: > This is an 6 year old patch that is still actively used: > > http://lists.nongnu.org/archive/html/quilt-dev/2008-01/msg00004.html > > Revised again here: > > http://comments.gmane.org/gmane.comp.handhelds.openembedded/34224 > > This patch was then updated to properly work with or without the > --backup option to the quilt refresh by using cat_to_new_file option > instead of mv for refresh. A reference to the QUILT_NO_RM_SYMLINKS was > also added to the usage information for quilt refresh.
Is there a legitimate use case for not setting QUILT_NO_RM_SYMLINKS? Quilt does not create symbolic links under patches, so if they are there, you must have created them on purpose and I can't think of any reason why you would want to break them. If that was the case, you would have created copies in the first place, or hard links. I appreciate that you are preserving compatibility with the current behavior but I suspect that this behavior is accidental rather than desired. The "rm" in cat_to_new_file was originally added to solve the problem of hard-linked copies of patch files being modified by "quilt refresh". Calling "rm" breaks the hard link so other copies are left untouched. I doubt that symbolic links were considered at that point (and this is why you have the problem you have.) So maybe it would be the right time to set a sane default behavior for them (and add option QUILT_RM_SYMLINKS later if anyone ever asks for it - but I suspect this won't happen.) What do you think? Opinion anyone? > (...) > @@ -324,7 +328,7 @@ if [ -e "$patch_file" ] && \ > then > printf $"Patch %s is unchanged\n" "$(print_patch "$patch")" > elif ( [ -z "$QUILT_BACKUP" -o ! -e "$patch_file" ] || \ > - mv "$patch_file" "$patch_file~" ) && \ > + cat_to_new_file "$patch_file~" < "$patch_file" ) && \ This comes with a small performance penalty in the general case. You probably won't notice it for a single patch, but people using the --refresh option of push or pop on large patch sets are likely to notice it. I wonder if this could be avoided, maybe by letting cat_to_new_file handle the backup by itself. > cat_to_new_file "$patch_file" < $tmp_result > then > if [ -n "$opt_fork" ] Thanks, -- Jean Delvare SUSE L3 Support _______________________________________________ Quilt-dev mailing list Quilt-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/quilt-dev
