git-quiltimport complaining yet still working

git-quiltimport complaining yet still working

[Greg KH]

In git 1.5.1 the quiltimport function started complaining in a new way:

	libata-clear-tf-before-doing-request-sense.patch
	Patch is empty.  Was is split wrong?
	/usr/bin/git-quiltimport: line 78: stop_here: command not found

yet it still applies the patch properly.

For an example of patches that causes this output, the -stable kernel
tree queue can be used (which is where I started seeing this problem...)

Any hints?  Or is it time to start bisecting?

thanks,

greg k-h

Re: git-quiltimport complaining yet still working

[Don Zickus]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On 4/13/07, Greg KH <greg@kroah.com> wrote:
> In git 1.5.1 the quiltimport function started complaining in a new way:
>
>         libata-clear-tf-before-doing-request-sense.patch
>         Patch is empty.  Was is split wrong?
>         /usr/bin/git-quiltimport: line 78: stop_here: command not found

Sorry about that.  I assumed all the scripts using git-mailinfo had
the stop_here command.  Not sure why I made that assumption.

I changed the behaviour of git-mailinfo to allow empty patches and
have the scripts check if a patch was empty and fail.  Unfortunately,
I incorrectly applied the change to git-quiltimport.

Anyway the following should fix it.

Signed-off-by: Don Zickus <dzickus@redhat.com>

[-- Attachment #2: don.patch --]
[-- Type: text/x-patch, Size: 461 bytes --]

diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index edccd82..0d20dc5 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -75,7 +75,7 @@ for patch_name in $(cat "$QUILT_PATCHES/series" | grep -v '^#'); do
 	(cat $QUILT_PATCHES/$patch_name | git-mailinfo "$tmp_msg" "$tmp_patch" > "$tmp_info") || exit 3
 	test -s $dotest/patch || {
 		echo "Patch is empty.  Was is split wrong?"
-		stop_here $this
+		exit 3
 	}
 
 	# Parse the author information

Re: git-quiltimport complaining yet still working

[Greg KH]

On Fri, Apr 13, 2007 at 05:13:58PM -0400, Don Zickus wrote:
> On 4/13/07, Greg KH <greg@kroah.com> wrote:
> >In git 1.5.1 the quiltimport function started complaining in a new way:
> >
> >        libata-clear-tf-before-doing-request-sense.patch
> >        Patch is empty.  Was is split wrong?
> >        /usr/bin/git-quiltimport: line 78: stop_here: command not found
> 
> Sorry about that.  I assumed all the scripts using git-mailinfo had
> the stop_here command.  Not sure why I made that assumption.
> 
> I changed the behaviour of git-mailinfo to allow empty patches and
> have the scripts check if a patch was empty and fail.  Unfortunately,
> I incorrectly applied the change to git-quiltimport.
> 
> Anyway the following should fix it.
> 
> Signed-off-by: Don Zickus <dzickus@redhat.com>

> diff --git a/git-quiltimport.sh b/git-quiltimport.sh
> index edccd82..0d20dc5 100755
> --- a/git-quiltimport.sh
> +++ b/git-quiltimport.sh
> @@ -75,7 +75,7 @@ for patch_name in $(cat "$QUILT_PATCHES/series" | grep -v '^#'); do
>  	(cat $QUILT_PATCHES/$patch_name | git-mailinfo "$tmp_msg" "$tmp_patch" > "$tmp_info") || exit 3
>  	test -s $dotest/patch || {
>  		echo "Patch is empty.  Was is split wrong?"
> -		stop_here $this
> +		exit 3

Are you sure?  This will exit, and yet, there was nothing really wrong
with the patch in the first place (as proven by the fact that it is
applied properly.)

Or did the patch format that can be accepted by git-quiltimport suddenly
change somehow?  I'm passing mbox-like files to it, and have been since
it was created.  To change this, is fine, but let me know what format
is now needed please.

thanks,

greg k-h

Re: git-quiltimport complaining yet still working

[Linus Torvalds]

On Fri, 13 Apr 2007, Greg KH wrote:
>
> In git 1.5.1 the quiltimport function started complaining in a new way:
> 
> 	libata-clear-tf-before-doing-request-sense.patch
> 	Patch is empty.  Was is split wrong?
> 	/usr/bin/git-quiltimport: line 78: stop_here: command not found

This is an *old* bug. It got fixed once already. Did it get re-introduced?

Ahh - somebody copied the bug from git-applymbox

> Any hints?  Or is it time to start bisecting?

This should fix it.

There were two bugs: "stop_here" doesn't exist, but the bug that causes 
this code to trigger in the *first* place is the wrong use of "$dotest". 
It should be ".dotest"

		Linus

---
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index edccd82..018cc75 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -73,9 +73,9 @@ mkdir $tmp_dir || exit 2
 for patch_name in $(cat "$QUILT_PATCHES/series" | grep -v '^#'); do
 	echo $patch_name
 	(cat $QUILT_PATCHES/$patch_name | git-mailinfo "$tmp_msg" "$tmp_patch" > "$tmp_info") || exit 3
-	test -s $dotest/patch || {
+	test -s .dotest/patch || {
 		echo "Patch is empty.  Was is split wrong?"
-		stop_here $this
+		exit 1
 	}
 
 	# Parse the author information

Re: git-quiltimport complaining yet still working

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> This should fix it.
>
> There were two bugs: "stop_here" doesn't exist, but the bug that causes 
> this code to trigger in the *first* place is the wrong use of "$dotest". 
> It should be ".dotest"

I am quite sure that I've said the same thing as above in my
earlier message to fix this exact thing, but as usual I appear
to have sent it to the list and then forgot to apply it myself.

Thanks.

Re: git-quiltimport complaining yet still working

[Greg KH]

On Fri, Apr 13, 2007 at 02:34:18PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 13 Apr 2007, Greg KH wrote:
> >
> > In git 1.5.1 the quiltimport function started complaining in a new way:
> > 
> > 	libata-clear-tf-before-doing-request-sense.patch
> > 	Patch is empty.  Was is split wrong?
> > 	/usr/bin/git-quiltimport: line 78: stop_here: command not found
> 
> This is an *old* bug. It got fixed once already. Did it get re-introduced?
> 
> Ahh - somebody copied the bug from git-applymbox
> 
> > Any hints?  Or is it time to start bisecting?
> 
> This should fix it.
> 
> There were two bugs: "stop_here" doesn't exist, but the bug that causes 
> this code to trigger in the *first* place is the wrong use of "$dotest". 
> It should be ".dotest"

Thanks, that seems to do the trick for me.

greg k-h