Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" [off-list ref] writes:

quoted

I actually find it awkward that author/summary information is never
shown during git commit - sometimes one does git commit
on a machine where GIT_AUTHOR_EMAIL has not been setup
correctly, and the result often is mst@mst-desktop.(none).

That is something that needs to be set up once.  I do not think
it justifies wasting three more lines (one of them being an
empty line) per every commit.

quoted

Or people sometimes forget that the first line will show up
in the pretty=short summary and the result is that what
ends up being there is just 2 first lines of the long description.

One has to remember to always do git log --pretty=short
after commit to verify that one did get these details right.

quoted

Ideas:
- Maybe have git-commit display shortlog summary for commit just created?

Hopefully this will make people fix the git config up and amend their commits themselves.
Does this sound like a good idea?

Maybe protect it with "[user] novice" in .git/config?  Otherwise
I think it gets too noisy once you get used to it. 

I think reviewing and fixing is best done in the editor (that's
why git-commit does not start reading from stdin when it expects
you to type a log message, but gives you an editor), and
pointing out a mistake after the fact, while it is probably
better than not pointing out at all, is not all that useful.  If
there is no mistake, it is just an added noise, and if there is
a mistake, the user needs to take another action (i.e. --amend)
to correct it.

I think a much better thing you could do is to have a mode that
the commit log message editor is started with something like
this...

	----------------------------------------------------------------
	From: A U Thor [off-list ref]
        Subject: << the summary of the commit comes here >>
        
	# << more detailed explanations come here >>
	# Please enter the commit message for your changes.
        # (comment lines starting with '#' will not be included)
	# On branch 'master'
        # Changes to be committed:
        # ...
	----------------------------------------------------------------

and teach git-commit to notice the first paragraph that is
formatted like RFC2822 headers, and do appropriate things.

"Something like" this patch, although this time I have these two
words in quotes because I know the part to unmunge the buffer
needs more work.

diff --git a/git-commit.sh b/git-commit.sh
index 292cf96..d7a7b0b 100755
--- a/git-commit.sh
+++ b/git-commit.sh

@@ -546,10 +546,13 @@ else
 fi
 set_reflog_action "$rloga"
 
+summary_mark='<< the summary of the commit comes here >>'
 if test -z "$no_edit"
 then
 	{
+		echo "$summary_mark"
 		echo ""
+		echo "# << more detailed explanations come here >>"
 		echo "# Please enter the commit message for your changes."
 		echo "# (Comment lines starting with '#' will not be included)"
 		test -z "$only_include_assumed" || echo "$only_include_assumed"

@@ -579,7 +582,34 @@ case "$no_edit" in
 	esac
 	git-var GIT_AUTHOR_IDENT > /dev/null  || die
 	git-var GIT_COMMITTER_IDENT > /dev/null  || die
-	${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"
+	{
+		echo "From: $(expr "$(git-var GIT_AUTHOR_IDENT)" : '\(.*>\)')"
+		sed -e '1s/^/Subject: /' "$GIT_DIR/COMMIT_EDITMSG"
+		echo ""
+	} >"$GIT_DIR/COMMIT_EDITMSG+"
+	mv "$GIT_DIR/COMMIT_EDITMSG+" "$GIT_DIR/COMMIT_EDITMSG"
+	${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG" || exit
+
+	AU=$(sed -n -e '
+		/^$/q
+		/^From: /{
+			s///p
+			q
+	}' "$GIT_DIR/COMMIT_EDITMSG")
+	if	test -n "$AU" &&
+		AN=$(expr "$AU" : '\(.*[^ ]\)  *<') &&
+		AE=$(expr "$AU" : '.*[^ ]  *<\(.*\)>$')
+	then
+		GIT_AUTHOR_NAME=$AN
+		GIT_AUTHOR_EMAIL=$AE
+		export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
+	fi
+	sed -e '
+		/^From: /d
+		/^Subject: '"$summary_mark"'/d
+		s/^Subject: //
+	' "$GIT_DIR/COMMIT_EDITMSG" >"$GIT_DIR/COMMIT_EDITMSG+"
+	mv "$GIT_DIR/COMMIT_EDITMSG+" "$GIT_DIR/COMMIT_EDITMSG"
 	;;
 esac
 

Quoting Junio C Hamano [off-list ref]:
Subject: Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" [off-list ref] writes:

quoted

quoted

I actually find it awkward that author/summary information is never
shown during git commit - sometimes one does git commit
on a machine where GIT_AUTHOR_EMAIL has not been setup
correctly, and the result often is mst@mst-desktop.(none).

That is something that needs to be set up once.  I do not think
it justifies wasting three more lines (one of them being an
empty line) per every commit.

quoted

quoted

Or people sometimes forget that the first line will show up
in the pretty=short summary and the result is that what
ends up being there is just 2 first lines of the long description.

One has to remember to always do git log --pretty=short
after commit to verify that one did get these details right.

quoted

quoted

Ideas:
- Maybe have git-commit display shortlog summary for commit just created?

Hopefully this will make people fix the git config up and amend their commits themselves.
Does this sound like a good idea?

I've been thinking about this idea some more recently.

Too noisy for a default.

How about only printing out the shortlog summary?

Maybe protect it with "[user] novice" in .git/config?

OK but [user] novice would have to be set by default then,
otherwise novice won't know he has to enable it :).

Otherwise
I think it gets too noisy once you get used to it. 

You are right. How about only doing this only if
the log message is multi-line, and there is no separate summary?

I think reviewing and fixing is best done in the editor (that's
why git-commit does not start reading from stdin when it expects
you to type a log message, but gives you an editor), and
pointing out a mistake after the fact, while it is probably
better than not pointing out at all, is not all that useful.  If
there is no mistake, it is just an added noise, and if there is
a mistake, the user needs to take another action (i.e. --amend)
to correct it.

I think a much better thing you could do is to have a mode that
the commit log message editor is started with something like
this...

This would work well for author information, but less well for shortlog.

 
-- 
MST

"Michael S. Tsirkin" [off-list ref] writes:

quoted

I think a much better thing you could do is to have a mode that
the commit log message editor is started with something like
this...

This would work well for author information, but less well for shortlog.

quoted

	----------------------------------------------------------------
	From: A U Thor [off-list ref]
     Subject: << one line summary of the commit comes here >>
        
	<< more detailed explanations come here >>
	# Please enter the commit message for your changes.
     # (comment lines starting with '#' will not be included)

Care to share your reasoning behind "less well for shortlog" part?

I think a template like the above makes absolutely clear that
your log would look like a single summary line, and a separate
body of text that explains your change fully, and I do not
understand your concern.

Quoting Junio C Hamano [off-list ref]:
Subject: Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" [off-list ref] writes:

quoted

quoted

I think a much better thing you could do is to have a mode that
the commit log message editor is started with something like
this...

This would work well for author information, but less well for shortlog.

quoted

	----------------------------------------------------------------
	From: A U Thor [off-list ref]
     Subject: << one line summary of the commit comes here >>
        
	<< more detailed explanations come here >>
	# Please enter the commit message for your changes.
     # (comment lines starting with '#' will not be included)

Care to share your reasoning behind "less well for shortlog" part?

I think a template like the above makes absolutely clear that
your log would look like a single summary line, and a separate
body of text that explains your change fully, and I do not
understand your concern.

I confess that I forget to add shortlog line myself sometimes,
and I feel that adding stuff inside comments won't help me
remember since I'm used to ignoring it.

Current git commit output looks like this:
	Created commit 2b7ca2abf7526f13ce334475e0c66f79fbb5c206
	1 files changed, 1 insertions(+), 0 deletions(-)

And I wander why does it tell me the new commit hash -
wouldn't displaying the subject make more sense?
Something like

	Created commit "Make foobar faster by caching more barbar in foo"
	1 files changed, 1 insertions(+), 0 deletions(-)

-- 
MST

On Sunday 2007, April 15, Michael S. Tsirkin wrote:

And I wander why does it tell me the new commit hash -
wouldn't displaying the subject make more sense?
Something like

	Created commit "Make foobar faster by caching more barbar in foo"
	1 files changed, 1 insertions(+), 0 deletions(-)

If you do a series of "git commit --amend"s, you would get an identical 
message each time.  Also, I've often found it convenient when doing 
resets, amends, patch splits and movements between branches to be able 
to cut and paste the commit hash still on the terminal into lines like

 git commit --amend -c $HASH

I wouldn't object to having the subject as well, but please don't lose 
the hash - it's very useful.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Quoting Andy Parkins [off-list ref]:
Subject: Re: [PATCH] display shortlog after git-commit

On Sunday 2007, April 15, Michael S. Tsirkin wrote:

quoted

And I wander why does it tell me the new commit hash -
wouldn't displaying the subject make more sense?
Something like

	Created commit "Make foobar faster by caching more barbar in foo"
	1 files changed, 1 insertions(+), 0 deletions(-)

If you do a series of "git commit --amend"s, you would get an identical 
message each time.  Also, I've often found it convenient when doing 
resets, amends, patch splits and movements between branches to be able 
to cut and paste the commit hash still on the terminal into lines like

 git commit --amend -c $HASH

I wouldn't object to having the subject as well, but please don't lose 
the hash - it's very useful.

Yes, I see how that would be useful with amends.

-- 
MST