quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] [PATCH] Add drop option to pop command


From: Jean Delvare
Subject: Re: [Quilt-dev] [PATCH] Add drop option to pop command
Date: Sun, 31 Jul 2005 22:35:27 +0200

Hi Josh,

> > As suggested a while ago, my proposed quilt drop command was so
> > similar to quilt pop that I've implemented it's functionality as an
> > option to pop instead.  Below is the patch.
> > 
> > Questions/comments always welcome.  If this is more acceptable for
> > inclusion, that's great.  And if not, that's ok too.  I can always
> > use quilt to keep it applied to my local copy ;).

Here comes my review of your patch.

> --- quilt.orig/quilt/pop.in
> +++ quilt/quilt/pop.in
> @@ -19,7 +19,7 @@ fi
>  
>  usage()
>  {
> -     printf $"Usage: quilt pop [-afRqv] [num|patch]\n"
> +     printf $"Usage: quilt pop [-adfRqv] [num|patch]\n"

I think I understand that -d and -R are mutually exclusive, so maybe
this should rather read:

Usage: quilt pop [-azqv] [-R|-d] [num|patch]

> +-d   Drop patch(es).  (Leaves them appiled to the source tree)

s/appiled/applied. Also, I think s/Leaves/Leave/ and a trailing dot
would be welcome.

> -             if [ -z "$(shopt -s nullglob ; echo "$QUILT_PC/$patch/"*)" ]
> +             if [ -n "$opt_drop" ]
>               then
> -                     printf $"Patch %s appears to be empty, removing\n" \
> -                            "$(print_patch $patch)"
> -                     status=0
> -             else
> -                     printf $"Removing patch %s\n" "$(print_patch $patch)"
> -                     @LIB@/backup-files $silent -r -t -B $QUILT_PC/$patch/ -
> +                     printf $"Dropping patch %s\n" "$(print_patch $patch)"
> +                     @LIB@/backup-files $silent -x -B $QUILT_PC/$patch/ -
>                       status=$?
> +                     remove_from_series $patch
> +             else
> +                     if [ -z "$(shopt -s nullglob ; echo 
> "$QUILT_PC/$patch/"*)" ]
> +                     then
> +                             printf $"Patch %s appears to be empty, 
> removing\n" \
> +                             "$(print_patch $patch)"
> +                             status=0
> +                     else
> +                             printf $"Removing patch %s\n" "$(print_patch 
> $patch)"
> +                             @LIB@/backup-files $silent -r -t -B 
> $QUILT_PC/$patch/ -
> +                             status=$?
> +                     fi

I'm curious what would happen if you tried -d on an empty patch. Would
it cause any problem? Even if it doesn't, it's probably still good to
let the user know, as this isn't supposed to happen.

> @@ -222,6 +232,10 @@ do
>       -a)
>               opt_all=1
>               shift ;;
> +     -d)
> +             opt_drop=1
> +             unset opt_remove
> +             shift ;;
>       -h)
>               usage -h ;;
>          --)

I don't like the fact that -d -R would do one thing and -R -d would do
something different. Also, silently ignoring an option is no good. I'd
prefer the script to exit with an error message if both -d and -R are
provided.

What would happen if a dropped patch included a file that is modified by
other patches below the dropped one? Looks to me like you would be left
in a state where you can't commit the changes to your source code
management system, nor can you pop the lower patch modifying this file
anymore, right? This doesn't sound good. As I understand it, dropping a
patch only makes sense if it affects files no patches below it affect.
Your patch should ensure that this is the case rather than blindly
trusting the user. I don't think we can accept your patch in mainline as
long as this point isn't addressed, as this would be too easy for a
random user to screw up his/her working tree.

-- 
Jean Delvare




reply via email to

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