[GIT PULL] sh updates for 2.6.25

[GIT PULL] sh updates for 2.6.25

[Paul Mundt]

Please pull from:

	master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.25.git

Which contains:

Adrian Bunk (1):
      sh64: add missing #include <asm/fpu.h>'s

Andrew Morton (2):
      sh: arch/sh/kernel/traps_32.c needs asm/fpu.h
      sh: export empty_zero_page

Manuel Lauss (1):
      sh: fix compressed kernel build

 arch/sh/boot/compressed/head_32.S |    1 -
 arch/sh/boot/compressed/head_64.S |    1 -
 arch/sh/kernel/process_64.c       |    1 +
 arch/sh/kernel/ptrace_64.c        |    1 +
 arch/sh/kernel/sh_ksyms_32.c      |    1 +
 arch/sh/kernel/sh_ksyms_64.c      |    1 +
 arch/sh/kernel/signal_64.c        |    1 +
 arch/sh/kernel/traps_32.c         |    1 +
 arch/sh/kernel/traps_64.c         |    1 +
 9 files changed, 7 insertions(+), 2 deletions(-)

Re: [GIT PULL] sh updates for 2.6.25

[Linus Torvalds]

On Wed, 16 Apr 2008, Paul Mundt wrote:
>
> Please pull from:
> 
> 	git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25.git

Paul, your git tree is odd. Not quite corrupt, but it doesn't really 
follow the rules either.

In particular, it has empty lines at the top of those commits, and I 
wonder how you created them. 

Doing things like "git log" will ignore the spurious empty lines, but they 
can be seen with things like "git cat-file", eg

	git cat-file commit fd785d6b18b930b76ad5076eed6e9af43195b281 

and I wonder if you used a buggy version of git, or whether you perhaps 
have some scripts that import these commits from the outside and uses some 
low-level commands that can generate these kinds of subtly bogus commits.

The reason I noticed is that it screws up the git merge summary, which 
will take the first line of each commit it merges (_without_ the "skip 
empty lines" logic) to generate the summary of the merge.

I think we should fix that git merge summary code to allow for this bad 
behaviour, but I also want to know why such corrupt commits exist in the 
first place. What toolchain do you use to create that commit? We should 
fix that too!

Junio? Something like this for the merge summary code? (It also turns an 
empty commit message with just whitespace in the commit message into the 
SHA1 hex string)

		Linus

----
 builtin-fmt-merge-msg.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index ebb3f37..7077d52 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -201,6 +201,15 @@ static void shortlog(const char *name, unsigned char *sha1,
 			continue;
 
 		bol = strstr(commit->buffer, "\n\n");
+		if (bol) {
+			unsigned char c;
+			do {
+				c = *++bol;
+			} while (isspace(c));
+			if (!c)
+				bol = NULL;
+		}
+
 		if (!bol) {
 			append_to_list(&subjects, xstrdup(sha1_to_hex(
 							commit->object.sha1)),
@@ -208,7 +217,6 @@ static void shortlog(const char *name, unsigned char *sha1,
 			continue;
 		}
 
-		bol += 2;
 		eol = strchr(bol, '\n');
 		if (eol) {
 			oneline = xmemdupz(bol, eol - bol);

Re: [GIT PULL] sh updates for 2.6.25

[Linus Torvalds]

On Tue, 15 Apr 2008, Linus Torvalds wrote:
> 
> Paul, your git tree is odd. Not quite corrupt, but it doesn't really 
> follow the rules either.

Anyway, I pulled the result (with my version of git that removes empty 
space at the beginning for the merge summary), and pushed it out. So it's 
merged, but I'd still like to know what tool actually created those extra 
spaces in the commit..

A regular "git commit" or "git am" should always strip whitespace. I 
assume it's something like stgit or other?

				Linus

Re: [GIT PULL] sh updates for 2.6.25

[Paul Mundt]

On Tue, Apr 15, 2008 at 11:01:36AM -0700, Linus Torvalds wrote:
> On Wed, 16 Apr 2008, Paul Mundt wrote:
> >
> > Please pull from:
> > 
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25.git
> 
> Paul, your git tree is odd. Not quite corrupt, but it doesn't really 
> follow the rules either.
> 
> In particular, it has empty lines at the top of those commits, and I 
> wonder how you created them. 
> 
> Doing things like "git log" will ignore the spurious empty lines, but they 
> can be seen with things like "git cat-file", eg
> 
> 	git cat-file commit fd785d6b18b930b76ad5076eed6e9af43195b281 
> 
> and I wonder if you used a buggy version of git, or whether you perhaps 
> have some scripts that import these commits from the outside and uses some 
> low-level commands that can generate these kinds of subtly bogus commits.

It was a combination of mbox munging and git-am, I checked with git log
and thought things were ok, but I wasn't aware that it stripped out empty
lines. cat-file shows that it was just the 2 patches from Andrew that had
this particular problem. I had stripped out the subject and thought the
first line would be used for the merge summary, but it looks like git-am
simply wrote out an empty line and inserted one after that before the
rest of the summary.

I've pushed out updated patches that have this corrected, so please pull
again.

Re: [GIT PULL] sh updates for 2.6.25

[Linus Torvalds]

On Wed, 16 Apr 2008, Paul Mundt wrote:
> 
> It was a combination of mbox munging and git-am, I checked with git log
> and thought things were ok, but I wasn't aware that it stripped out empty
> lines. cat-file shows that it was just the 2 patches from Andrew that had
> this particular problem. I had stripped out the subject and thought the
> first line would be used for the merge summary, but it looks like git-am
> simply wrote out an empty line and inserted one after that before the
> rest of the summary.

Ahh, looks like a git-am buglet then. It will indeed turn an empty subject 
line into an empty first line.

We should run "git stripspace" on the whole thing, so maybe a patch 
something like the appended will help.

NOTE! Totally untested! Beware the patch!

> I've pushed out updated patches that have this corrected, so please pull
> again.

Well, since I pulled your previous one anyway, and since we should fix 
git for any fallout like this _anyway_, I didn't so much worry about this 
one-time event, as about avoiding this happening a lot in the future.

We've had other workflows generate empty lines in commits, so we already 
support stripping them out for other reasons.

			Linus
---
 git-am.sh |   23 +++++++++--------------
 1 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/git-am.sh b/git-am.sh
index ac5c388..432d9fe 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -107,7 +107,7 @@ It does not apply to blobs recorded in its index."
     # patch did not touch, so recursive ends up canceling them,
     # saying that we reverted all those changes.
 
-    eval GITHEAD_$his_tree='"$SUBJECT"'
+    eval GITHEAD_$his_tree='"$FIRSTLINE"'
     export GITHEAD_$his_tree
     git-merge-recursive $orig_tree -- HEAD $his_tree || {
 	    git rerere
@@ -117,10 +117,6 @@ It does not apply to blobs recorded in its index."
     unset GITHEAD_$his_tree
 }
 
-reread_subject () {
-	git stripspace <"$1" | sed -e 1q
-}
-
 prec=4
 dotest=".dotest"
 sign= utf8=t keep= skip= interactive= resolved= binary= rebasing@@ -331,7 +327,11 @@ do
 			echo "Patch is empty.  Was it split wrong?"
 			stop_here $this
 		}
-		git stripspace < "$dotest/msg" > "$dotest/msg-clean"
+		SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
+		case "$keep_subject" in -k)  SUBJECT="[PATCH] $SUBJECT" ;; esac
+
+		(echo "$SUBJECT" ; echo ; cat "$dotest/msg") |
+			git stripspace > "$dotest/msg-clean"
 		;;
 	esac
 
@@ -347,9 +347,6 @@ do
 
 	export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
 
-	SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
-	case "$keep_subject" in -k)  SUBJECT="[PATCH] $SUBJECT" ;; esac
-
 	case "$resume" in
 	'')
 	    if test '' != "$SIGNOFF"
@@ -368,10 +365,8 @@ do
 		ADD_SIGNOFF 	    fi
 	    {
-		printf '%s\n' "$SUBJECT"
 		if test -s "$dotest/msg-clean"
 		then
-			echo
 			cat "$dotest/msg-clean"
 		fi
 		if test '' != "$ADD_SIGNOFF"
@@ -388,6 +383,7 @@ do
 			;;
 		esac
 	esac
+	FIRSTLINE=$(head -1 "$dotest/final-commit")
 
 	resume 	if test "$interactive" = t
@@ -408,7 +404,6 @@ do
 		[aA]*) action=yes interactive= ;;
 		[nN]*) action=skip ;;
 		[eE]*) git_editor "$dotest/final-commit"
-		       SUBJECT=$(reread_subject "$dotest/final-commit")
 		       action=again ;;
 		[vV]*) action=again
 		       LESS=-S ${PAGER:-less} "$dotest/patch" ;;
@@ -431,7 +426,7 @@ do
 		stop_here $this
 	fi
 
-	printf 'Applying %s\n' "$SUBJECT"
+	printf 'Applying %s\n' "$FIRSTLINE"
 
 	case "$resolved" in
 	'')
@@ -489,7 +484,7 @@ do
 	tree=$(git write-tree) &&
 	parent=$(git rev-parse --verify HEAD) &&
 	commit=$(git commit-tree $tree -p $parent <"$dotest/final-commit") &&
-	git update-ref -m "$GIT_REFLOG_ACTION: $SUBJECT" HEAD $commit $parent ||
+	git update-ref -m "$GIT_REFLOG_ACTION: $FIRSTLINE" HEAD $commit $parent ||
 	stop_here $this
 
 	if test -x "$GIT_DIR"/hooks/post-applypatch

Re: [GIT PULL] sh updates for 2.6.25

[Alex Riesen]

Linus Torvalds, Tue, Apr 15, 2008 21:56:50 +0200:
> 
> 
> On Wed, 16 Apr 2008, Paul Mundt wrote:
> > 
> > It was a combination of mbox munging and git-am, I checked with git log
> > and thought things were ok, but I wasn't aware that it stripped out empty
> > lines. cat-file shows that it was just the 2 patches from Andrew that had
> > this particular problem. I had stripped out the subject and thought the
> > first line would be used for the merge summary, but it looks like git-am
> > simply wrote out an empty line and inserted one after that before the
> > rest of the summary.
> 
> Ahh, looks like a git-am buglet then. It will indeed turn an empty subject 
> line into an empty first line.
> 
> We should run "git stripspace" on the whole thing, so maybe a patch 
> something like the appended will help.
> 
> NOTE! Totally untested! Beware the patch!
> 

t4014-format-patch.sh broke. It probably has to be updated

Re: [GIT PULL] sh updates for 2.6.25

[Junio C Hamano]

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

> Junio? Something like this for the merge summary code? (It also turns an 
> empty commit message with just whitespace in the commit message into the 
> SHA1 hex string)

Yeah, your patch makes sense, but it also makes me wonder if we should fix
the code in pretty.c::parse_commit_header() that grabs the "subject" line,
and use format_commit_message() with "%s" format here.  Interested people
then can enhance it to take custom format string.

> 		Linus
>
> ----
>  builtin-fmt-merge-msg.c |   10 +++++++++-
>  1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
> index ebb3f37..7077d52 100644
> --- a/builtin-fmt-merge-msg.c
> +++ b/builtin-fmt-merge-msg.c
> @@ -201,6 +201,15 @@ static void shortlog(const char *name, unsigned char *sha1,
>  			continue;
>  
>  		bol = strstr(commit->buffer, "\n\n");
> +		if (bol) {
> +			unsigned char c;
> +			do {
> +				c = *++bol;
> +			} while (isspace(c));
> +			if (!c)
> +				bol = NULL;
> +		}
> +
>  		if (!bol) {
>  			append_to_list(&subjects, xstrdup(sha1_to_hex(
>  							commit->object.sha1)),
> @@ -208,7 +217,6 @@ static void shortlog(const char *name, unsigned char *sha1,
>  			continue;
>  		}
>  
> -		bol += 2;
>  		eol = strchr(bol, '\n');
>  		if (eol) {
>  			oneline = xmemdupz(bol, eol - bol);

Re: [GIT PULL] sh updates for 2.6.25

[David Woodhouse]

On Tue, 2008-04-15 at 11:01 -0700, Linus Torvalds wrote:
> Paul, your git tree is odd. Not quite corrupt, but it doesn't really 
> follow the rules either.
> 
> In particular, it has empty lines at the top of those commits, and I 
> wonder how you created them. 

Hm, I noticed those go past on the commits list and meant to
investigate, but got distracted before I got round to it. Should I
assume there's nothing to fix in the script which feeds the list, then?

$todo--; :)

-- 
dwmw2