On 9/27/07, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Dan Nicholson" <dbn.lists@xxxxxxxxx> writes: > > > When you run the command `quilt series', it just lists what's in the > > series file (minus any comments). And when you run `quilt push' with a > > non-existent patch, it says "Patch foo.patch does not exist; applied > > empty patch" > > > > So, I think the consistent thing to do is what's in my patch: just > > skip the patch with a message to the user. Maybe the message can be > > tailored to match quilt's output. Actually, it would be best to also > > skip on empty files since quiltimport will bomb in that case as well. > > Thanks for your helpful explanation. So perhaps we can do this > on top of yours to be safer and more consistent. > > --- > > git-quiltimport.sh | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/git-quiltimport.sh b/git-quiltimport.sh > index 880c81d..627e023 100755 > --- a/git-quiltimport.sh > +++ b/git-quiltimport.sh > @@ -79,8 +79,8 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do > git mailinfo "$tmp_msg" "$tmp_patch" \ > <"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3 > test -s "$tmp_patch" || { > - echo "Patch is empty. Was it split wrong?" > - exit 1 > + echo "Patch is empty. Skipping." > + continue > } > > # Parse the author information That's seems fine. IIUC, mailinfo will only create an empty patch if there's no actual patch content in the original mail/patch. In that case, you probably do want to skip and not bomb. I'd changed my patch to do 'if ! [ -s "$patch" ]' to catch an empty file, but this is probably better. Hmm, checking `quilt push' on a patch with no actual patch bombs. Here's the output: $ quilt push Applying patch foo.patch patch: **** Only garbage was found in the patch input. Patch foo.patch does not apply (enforce with -f) $ echo $? 1 $ cat patches/foo.patch Here's info about an empty patch. So, it might be better to leave the original behavior there to match quilt. -- Dan - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html