threads / patch / 7346

patchhave merge put FETCH_HEAD data in commit message

Subject: [PATCH] have merge put FETCH_HEAD data in commit message

## tl;dr

70 messages between Mar 21, 2007 and Apr 17, 2007. Diffs are folded; open one to read it.

replies: 69people: 9as markdown or json

Michael S. Tsirkin· Mar 21, 2007, 12:06 UTC · lore

Hi! I often like to fetch some code from others, review and then merge. So:

git fetch <URL> git log -p FETCH_HEAD git merge FETCH_HEAD

which is all good but gets me this message in commit log:
    Merge commit 'FETCH_HEAD' into master

which is not very informative. I can always fix this up with git commit --amend, but I'd like to avoid the extra step.

Would the following patch be appropriate?
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Show changes to git-merge.sh +4 −0
diff --git a/git-merge.sh b/git-merge.sh
index 8759c5a..629611b 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -108,6 +108,10 @@ merge_name () {
 		git-show-ref -q --verify "refs/heads/$truname" 2>/dev/null
 	then
 		echo "$rh		branch '$truname' (early part) of ."
+	elif test -r "$GIT_DIR/$remote"
+	then
+		echo -n "$rh		"
+		grep -v not-for-merge "$GIT_DIR/$remote"
 	else
 		echo "$rh		commit '$remote'"
 	fi
Junio C Hamano· Mar 21, 2007, 15:37 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 19 quoted lines
> Hi!
> I often like to fetch some code from others, review and
> then merge. So:
>
> git fetch <URL>
> git log -p FETCH_HEAD
> git merge FETCH_HEAD
>
> which is all good but gets me this message in commit log:
>
>     Merge commit 'FETCH_HEAD' into master
>
> which is not very informative.
> I can always fix this up with git commit --amend, but
> I'd like to avoid the extra step.
>
> Would the following patch be appropriate?
>
> Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>

Would "Hi!" and "Would the following be appropriate?" be part of the final commit log message?

I often hear from people who seems to like "fetch & merge", instead of "pull & reset ORIG_HEAD", as a workflow to avoid undesirable merging. This might largely be a matter of taste, but from philosophical point of view, fetch & merge is a sign of distrust (your default is not to merge, and you merge only when you choose to), and pull & reset is the opposite (your default is to merge, and after you inspect you may choose not to merge). Tool support to encourage the former feels somewhat wrong.

Having said that, since that comes up every now and then, I suspect it might make sense to have an optional behaviour in "git pull" that lets you say...

	$ git pull --preview $URL $refspec
which runs the following:
	. git fetch
        . git log -p `sed -e '/	not-for-merge	/d'\
        .	-e 's/	.*//' $GIT_DIR/FETCH_HEAD` \
        .	--not HEAD
	. asks you if you want to conclude this with a merge
	. git merge if told, otherwise abort.

The "git-log" above reads "give me the commits that are reachable from commits that are scheduled for merge but not in the current HEAD", i.e. the ones that will get merged.

Show 15 quoted lines
> diff --git a/git-merge.sh b/git-merge.sh
> index 8759c5a..629611b 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -108,6 +108,10 @@ merge_name () {
>  		git-show-ref -q --verify "refs/heads/$truname" 2>/dev/null
>  	then
>  		echo "$rh		branch '$truname' (early part) of ."
> +	elif test -r "$GIT_DIR/$remote"
> +	then
> +		echo -n "$rh		"
> +		grep -v not-for-merge "$GIT_DIR/$remote"
>  	else
>  		echo "$rh		commit '$remote'"
>  	fi

This 'not-for-merge' grep is only good while merging FETCH_HEAD, and will not work for any other random stuff in "$GIT_DIR", so at least it should be more specific, not just checking if it is the name of a readable file in $GIT_DIR. Somebody might find good usecases for doing "git merge ORIG_HEAD" or "git merge refs/bases/tutorial", for example, and your echo & grep would do something "interesting".

Every time I added "echo -n" from my sloppiness, somebody sent in a patch to replace it with "printf". I think people on non Linux platforms would hate you for using "echo -n" (I should bug Tytso about this with git-mergetool).

I am not sure what you meant by echo -n and grep -v. Other codepaths in the if-else chain seems to create $rh (the value of the single commit being merged) followed by two tabs followed by the message, and each line in $GIT_DIR/FETCH_HEAD is already in that format, so I suspect your code duplicates the commit object name twice?

Even when you fetch more than one branch in FETCH_HEAD, using FETCH_HEAD as an SHA-1 expression always picks up the object name on the first line (iow "git merge FETCH_HEAD" will not create an Octopus), so grepping for lines without not-for-merge marker is not correct either.

You would probably want something like:
		...
	elif test FETCH_HEAD = "$remote" && test -r "$GIT_DIR/FETCH_HEAD"
        then
        	sed -e 's/	not-for-merge	/		/' \
		    -e 1q "$GIT_DIR/FETCH_HEAD"
	else
        	...
Michael S. Tsirkin· Mar 22, 2007, 05:02 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Show 5 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
> 
> Would "Hi!" and "Would the following be appropriate?" be part of
> the final commit log message?

Sigh. I wish there was a way to tell git-am "ignore text *before* this line" just like --- means ignore text after this line.

-- 
MST
Junio C Hamano· Mar 22, 2007, 05:09 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 8 quoted lines
>> Quoting Junio C Hamano <junkio@cox.net>:
>> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
>> 
>> Would "Hi!" and "Would the following be appropriate?" be part of
>> the final commit log message?
>
> Sigh. I wish there was a way to tell git-am "ignore text *before* this line"
> just like --- means ignore text after this line.
Well, I'd sigh back.  I wish people imitated good examples, such as:
Message-ID: <Pine.LNX.4.63.0703220240590.4045@wbgn013.biozentrum.uni-wuerzburg.de>
which is not too hard to follow.
Michael S. Tsirkin· Mar 22, 2007, 06:28 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Show 17 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> >> Quoting Junio C Hamano <junkio@cox.net>:
> >> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
> >> 
> >> Would "Hi!" and "Would the following be appropriate?" be part of
> >> the final commit log message?
> >
> > Sigh. I wish there was a way to tell git-am "ignore text *before* this line"
> > just like --- means ignore text after this line.
> 
> Well, I'd sigh back.  I wish people imitated good examples, such as:
> 
> Message-ID: <Pine.LNX.4.63.0703220240590.4045@wbgn013.biozentrum.uni-wuerzburg.de>

I know that's how git-am wants the input to look. But I claim that's not how most people *think* or *correspond*.

> which is not too hard to follow.

BTW, is there some way to figure it out besides looking at the code or grepping git archives?

-- 
MST
Junio C Hamano· Mar 22, 2007, 07:15 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> BTW, is there some way to figure it out besides looking at the code
> or grepping git archives?
Like SubmittingPatches?
Michael S. Tsirkin· Mar 22, 2007, 07:41 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Show 9 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> > BTW, is there some way to figure it out besides looking at the code
> > or grepping git archives?
> 
> Like SubmittingPatches?

SubmittingPatches is for people contributing to git. But how are *users* of git-am supposed to figure it out?

-- 
MST
Junio C Hamano· Mar 22, 2007, 08:21 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 12 quoted lines
>> Quoting Junio C Hamano <junkio@cox.net>:
>> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
>> 
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 
>> > BTW, is there some way to figure it out besides looking at the code
>> > or grepping git archives?
>> 
>> Like SubmittingPatches?
>
> SubmittingPatches is for people contributing to git.
> But how are *users* of git-am supposed to figure it out?
(1) SubmittingPatches describes the git project policy on patch
    formatting, which happens to be similar to the kernel
    project.
(2) Users of git-am, git-format-patch and friends in general are
    not bound by SubmittingPatches, unless they are contributing
    to the git project.  As the policy differs from project to
    project, there is nothing authoritative in git documentation
    set, nor there should be anything stronger than merely our
    recommendation.  Yes, SubmittingPatches could be used as one
    potential BCP that is managed with git, but we are not in
    any position to impose that to other projects.  In other
    words, *users* of git-am are not supposed to figure it out.
    They will not find *their* project policy from git
    documentation, unless their project happens to be the git
    project.
(3) However, we are discussing your patch to support "git merge
    FETCH_HEAD" better, which I took as your contribution to the
    git project.  I asked you to follow the project policy for
    your contribution, and pointed at the document that
    describes the policy.
Clear?

I think your patch means well, and when polished it might be a valuable addition. "Hi!" and "Would the following be appropriate?" are the least of the problems I pointed out, but to clear the dust, let's finish them with responses: "Hi to you!", and "Yes, what the patch tries to do looks very nice, but there are a few issues I would want you to resolve" ;-).

To reiterate the more important points (this is also for my own purpose because I do not want the patch lost in this noise we are making):

 - Checking readability of $GIT_DIR/$remote itself is too loose;
   the name FETCH_HEAD should explicitly be checked, as that is
   the file that has the specific format that is understood by
   fmt-merge-msg.
 - "echo -n" is to be avoided for portability.
 - "git fetch $URL foo bar" would leave two lines in FETCH_HEAD;
   subsequent "git merge FETCH_HEAD" would merge only foo.  Pick
   the first line, stripping out not-for-merge marker and let it
   processed by fmt-merge-msg.
Michael S. Tsirkin· Mar 22, 2007, 08:37 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Show 5 quoted lines
> (2) ... In other
>     words, *users* of git-am are not supposed to figure it out.
>     They will not find *their* project policy from git
>     documentation, unless their project happens to be the git
>     project.

But if they don't use the same formatting as git policy requires, git-am will produce a mess of a log, until they discover the only policy that works with git-am by word of mouth.

Specifically, as far as a *user* is concerned:
1. the fact that "---" separates commit message from patch, and
   that text after "---" is ignored seems to be undocumented
2. the fact that message subject is appended to the log,
   the rules for removing [PATCH] etc from subject seem to be undocumented
3. if I want to have some text coming *before* the commit
   message ignored, there's no way to do this
4. there's no way to override the subject from within the message
   (like there is with author/From line)
Show 5 quoted lines
> (3) However, we are discussing your patch to support "git merge
>     FETCH_HEAD" better, which I took as your contribution to the
>     git project.  I asked you to follow the project policy for
>     your contribution, and pointed at the document that
>     describes the policy.
Amen to that, sorry about the formatting.
Show 15 quoted lines
> To reiterate the more important points (this is also for my own
> purpose because I do not want the patch lost in this noise we
> are making):
> 
>  - Checking readability of $GIT_DIR/$remote itself is too loose;
>    the name FETCH_HEAD should explicitly be checked, as that is
>    the file that has the specific format that is understood by
>    fmt-merge-msg.
> 
>  - "echo -n" is to be avoided for portability.
> 
>  - "git fetch $URL foo bar" would leave two lines in FETCH_HEAD;
>    subsequent "git merge FETCH_HEAD" would merge only foo.  Pick
>    the first line, stripping out not-for-merge marker and let it
>    processed by fmt-merge-msg.
Thanks, I'll try to address these.
-- 
MST
Junio C Hamano· Mar 22, 2007, 10:31 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 9 quoted lines
> Specifically, as far as a *user* is concerned:
> 1. the fact that "---" separates commit message from patch, and
>    that text after "---" is ignored seems to be undocumented
> 2. the fact that message subject is appended to the log,
>    the rules for removing [PATCH] etc from subject seem to be undocumented
> 3. if I want to have some text coming *before* the commit
>    message ignored, there's no way to do this
> 4. there's no way to override the subject from within the message
>    (like there is with author/From line)

How about this? Also check t5100 and its sample mailbox, especially the "third patch" from A U Thor, which I forwarded with the subject "another patch".

---
 Documentation/git-am.txt |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
Show changes to Documentation/git-am.txt +27 −0
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 13a7389..148ce40 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -87,6 +87,33 @@ default.   You could use `--no-utf8` to override this.
 DISCUSSION
 ----------
 
+The commit author name is taken from the "From: " line of the
+message, and commit author time is taken from the "Date: " line
+of the message.  The "Subject: " line is used as the title of
+the commit, after stripping common prefix "[PATCH <anything>]".
+It is supposed to describe what the commit is about concisely as
+a one line text.
+
+The body of the message (iow, after a blank line that terminates
+RFC2822 headers) can begin with "Subject: " and "From: " lines
+that are different from those of the mail header, to override
+the values of these fields.
+
+The commit message is formed by the title taken from the
+"Subject: ", a blank line and the body of the message up to
+where the patch begins.  Excess whitespaces at the end of the
+lines are automatically stripped.
+
+The patch is expected to be inline, directly following the
+message.  Any line that is of form:
+
+* three-dashes and end-of-line, or
+* a line that begins with "diff -", or
+* a line that begins with "Index: "
+
+is taken as the beginning of a patch, and the commit log message
+is terminated before the first occurrence of such a line.
+
 When initially invoking it, you give it names of the mailboxes
 to crunch.  Upon seeing the first patch that does not apply, it
 aborts in the middle, just like 'git-applymbox' does.  You can
Michael S. Tsirkin· Mar 22, 2007, 10:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Show 16 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> > Specifically, as far as a *user* is concerned:
> > 1. the fact that "---" separates commit message from patch, and
> >    that text after "---" is ignored seems to be undocumented
> > 2. the fact that message subject is appended to the log,
> >    the rules for removing [PATCH] etc from subject seem to be undocumented
> > 3. if I want to have some text coming *before* the commit
> >    message ignored, there's no way to do this
> > 4. there's no way to override the subject from within the message
> >    (like there is with author/From line)
> 
> How about this?
Looks good. What about 3?
Show 5 quoted lines
> 
> 
> Also check t5100 and its sample mailbox,
> especially the "third patch" from A U Thor, which I forwarded
> with the subject "another patch".
It's funny ... but what should I look at there, specifically?
-- 
MST
Junio C Hamano· Mar 24, 2007, 10:21 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 8 quoted lines
>> > 3. if I want to have some text coming *before* the commit
>> >    message ignored, there's no way to do this
>> > 4. there's no way to override the subject from within the message
>> >    (like there is with author/From line)
>> 
>> How about this?
>
> Looks good. What about 3?

When e-mailed message has garbage at the beginning (e.g. "Hi!"), git users can either run "commit --amend" immiediately after "git am", or edit the mbox with editor before running "applymbox", so the need has not been felt much us, and that is the primary reason why it is not there. Additionally we do not think it is particularly a good practice to have "cover letters" at the top (cf. $gmane/5418), so it was never high priority for us to add that feature to encourage such a practice.

Having said that, on top of the recent work by Don Zickus on mailinfo, you _could_ add support for scissors "^-- >8 --$" if you want.

Show 5 quoted lines
>> Also check t5100 and its sample mailbox,
>> especially the "third patch" from A U Thor, which I forwarded
>> with the subject "another patch".
>
> It's funny ... but what should I look at there, specifically?
It is an example that you can override Subject: (#4 above).
Michael S. Tsirkin· Apr 4, 2007, 06:02 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Quoting Junio C Hamano <junkio@cox.net>:
Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
Show 14 quoted lines
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> >> > 3. if I want to have some text coming *before* the commit
> >> >    message ignored, there's no way to do this
> >> > 4. there's no way to override the subject from within the message
> >> >    (like there is with author/From line)
> >> 
> >> How about this?
> >
> > Looks good. What about 3?
> 
> When e-mailed message has garbage at the beginning (e.g. "Hi!"),
> git users can either run "commit --amend" immiediately after
> "git am",

This one would overwrite the authorship information though, would it not? I actually wished several times for an --amend-message commit flag that would only edit the message, preserving the author (and possibly date?) metadata. Of course, I simply copy the author and pass it in --author, but it's somewhat awkward to do. Do others notice this?

*Maybe* git can be even smarter, and notice that only commit message has changed, and preserve the author automatically in this case? I haven't looked at how hard that would be to do.

<rant> 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). 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.

Ideas:
- Maybe have git-commit display shortlog summary for commit just created?
- Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
  commit message, and let the user edit them?
</rant>
Show 10 quoted lines
> or edit the mbox with editor before running
> "applymbox", so the need has not been felt much us, and that is
> the primary reason why it is not there.  Additionally we do not
> think it is particularly a good practice to have "cover letters"
> at the top (cf. $gmane/5418), so it was never high priority for
> us to add that feature to encourage such a practice.
> 
> Having said that, on top of the recent work by Don Zickus on
> mailinfo, you _could_ add support for scissors "^-- >8 --$" if
> you want.

OK, I thought about this a bit - if the message includes a cover letter, I think it's also likely to have an incorrect subject too. So how about simply ignoring text before Subject:/From: lines? This makes more sense, for me, than inventing yet another git-specific convention. Does this for you?

-- 
MST
Junio C Hamano· Apr 4, 2007, 06:09 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 14 quoted lines
>> When e-mailed message has garbage at the beginning (e.g. "Hi!"),
>> git users can either run "commit --amend" immiediately after
>> "git am",
>
> This one would overwrite the authorship information though,
> would it not? I actually wished several times for an --amend-message
> commit flag that would only edit the message, preserving the author
> (and possibly date?) metadata.
> Of course, I simply copy the author and pass it in --author,
> but it's somewhat awkward to do. Do others notice this?
>
> *Maybe* git can be even smarter, and notice that only
> commit message has changed, and preserve the author automatically
> in this case? I haven't looked at how hard that would be to do.

Maybe you can try what you complain about out before you rant? I amend other people's commit messages after the fact almost *every* *day*.

Michael S. Tsirkin· Apr 4, 2007, 06:18 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Show 10 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
> 
> > *Maybe* git can be even smarter, and notice that only
> > commit message has changed, and preserve the author automatically
> > in this case? I haven't looked at how hard that would be to do.
> 
> Maybe you can try what you complain about out before you rant?
> I amend other people's commit messages after the fact almost
> *every* *day*.
Right. Sorry.
-- 
MST
Shawn O. Pearce· Apr 4, 2007, 06:19 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Junio C Hamano <junkio@cox.net> wrote:
Show 8 quoted lines
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> > *Maybe* git can be even smarter, and notice that only
> > commit message has changed, and preserve the author automatically
> > in this case? I haven't looked at how hard that would be to do.
> 
> Maybe you can try what you complain about out before you rant?
> I amend other people's commit messages after the fact almost
> *every* *day*.

Me too. And I *know* Junio amends my stuff after applying it to git.git. Just look back at the history to see how many thinkos he's saved me from... ;-)

-- 
Shawn.
Junio C Hamano· Apr 4, 2007, 06:25 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 13 quoted lines
> Junio C Hamano <junkio@cox.net> wrote:
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> > *Maybe* git can be even smarter, and notice that only
>> > commit message has changed, and preserve the author automatically
>> > in this case? I haven't looked at how hard that would be to do.
>> 
>> Maybe you can try what you complain about out before you rant?
>> I amend other people's commit messages after the fact almost
>> *every* *day*.
>
> Me too.  And I *know* Junio amends my stuff after applying it to
> git.git.  Just look back at the history to see how many thinkos
> he's saved me from...  ;-)

Actually, you cannot know. I may well be editing your mesage in my mailbox before applying, like Linus does.

Shawn O. Pearce· Apr 4, 2007, 06:35 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Junio C Hamano <junkio@cox.net> wrote:
Show 7 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Me too.  And I *know* Junio amends my stuff after applying it to
> > git.git.  Just look back at the history to see how many thinkos
> > he's saved me from...  ;-)
> 
> Actually, you cannot know.  I may well be editing your mesage in
> my mailbox before applying, like Linus does.

OK, yes, good point. So maybe my garbage is easier to fix in your email client then with --amend. ;-)

But the point of you saving me still holds!

Although 1510fea7 sadly was not one of those times... ;-) At least it was fixed by 5caf9232.

-- 
Shawn.
Junio C Hamano· Apr 4, 2007, 06:24 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 63 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
>
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 
>> >> > 3. if I want to have some text coming *before* the commit
>> >> >    message ignored, there's no way to do this
>> >> > 4. there's no way to override the subject from within the message
>> >> >    (like there is with author/From line)
>> >> 
>> >> How about this?
>> >
>> > Looks good. What about 3?
>> 
>> When e-mailed message has garbage at the beginning (e.g. "Hi!"),
>> git users can either run "commit --amend" immiediately after
>> "git am",
>
> This one would overwrite the authorship information though,
> would it not? I actually wished several times for an --amend-message
> commit flag that would only edit the message, preserving the author
> (and possibly date?) metadata.
> Of course, I simply copy the author and pass it in --author,
> but it's somewhat awkward to do. Do others notice this?
>
> *Maybe* git can be even smarter, and notice that only
> commit message has changed, and preserve the author automatically
> in this case? I haven't looked at how hard that would be to do.
>
> <rant>
> 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).
> 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.
>
> Ideas:
> - Maybe have git-commit display shortlog summary for commit just created?
> - Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
>   commit message, and let the user edit them?
> </rant>
>
>> or edit the mbox with editor before running
>> "applymbox", so the need has not been felt much us, and that is
>> the primary reason why it is not there.  Additionally we do not
>> think it is particularly a good practice to have "cover letters"
>> at the top (cf. $gmane/5418), so it was never high priority for
>> us to add that feature to encourage such a practice.
>> 
>> Having said that, on top of the recent work by Don Zickus on
>> mailinfo, you _could_ add support for scissors "^-- >8 --$" if
>> you want.
>
> OK, I thought about this a bit - if the message includes a
> cover letter, I think it's also likely to have an incorrect
> subject too. So how about simply ignoring text before
> Subject:/From: lines? This makes more sense, for me, than
> inventing yet another git-specific convention. Does this for you?
People sometimes say something like:
    From: Quim K Holland <qkholland@cox.net>
    Date: Wed, 4 Apr 2007 09:02:13 +0300
    Subject: [PATCH] Fix frobnitz while nitfol is in use
    Message-Id: <20070404060213.GB31984@filfre.cox.net>
    Earlier Sloof Lirpa reported that frobnitz feature has problems
    when nitfol is running background in this message:
    From: Sloof Lirpa <sitemaster@cox.net>
    Subject: [BUG] frobnitz garbles its output
    Message-Id: <20070403060213.GB31984@frotz.cox.net>
    Upon closer inspection, the problem is caused by filfre
    function firing up prematurely because nitfol process grabs
    semaphore and never releases it.  Here is a patch to fix
    this issue...
    Signed-off-by: Quim K Holland <qkholland@cox.net>
    ---
    diff --git a/... b/...

And that is why we do not even pick up the From: and stuff in the middle of the message.

We might be able to convince people to adopt a convention to use an explicit mark to signal the end of cover letter (or maybe make it an option in .git/config), but one thing we do not absolutely want to do is to pick up "^(From|Date|Subject): " from any random place in the middle of message, let alone discarding what comes before them.

That is, something like the following might be acceptable instead:

    From: Sloof Lirpa <sitemaster@cox.net>
    Subject: [BUG] frobnitz garbles its output
    Message-Id: <20070403060213.GB31984@frotz.cox.net>
    Quim K Holland's patch fixes the problem I reported earlier,
    so I am forwarding his patch.  Please apply.
    -- >8 --
    From: Quim K Holland <qkholland@cox.net>
    Date: Wed, 4 Apr 2007 09:02:13 +0300
    Subject: [PATCH] Fix frobnitz while nitfol is in use
    Message-Id: <20070404060213.GB31984@filfre.cox.net>
    Earlier Sloof Lirpa reported that frobnitz feature has problems
    when nitfol is running background in this message:
    Upon closer inspection, the problem is caused by filfre
    function firing up prematurely because nitfol process grabs
    semaphore and never releases it.  Here is a patch to fix
    this issue...
    Signed-off-by: Quim K Holland <qkholland@cox.net>
    ---
    diff --git a/... b/...
Michael S. Tsirkin· Apr 4, 2007, 07:01 UTC · re: Junio C Hamano · lore

[PATCH] display shortlog after git-commit

This might be useful to make people review their log messages as recorded by git, to make sure they match project guidelines: among the things most commonly misconfigured are author mail, and the commit title line.

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Show 13 quoted lines
> 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).
> 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.
>
> 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? BTW, it's a pity that --no-commit-id breaks --pretty=short. Maybe use something like --pretty='format:Author: %an <%ae>%n%s' instead?

Show changes to git-commit.sh +1 −1
diff --git a/git-commit.sh b/git-commit.sh
index 292cf96..88e487f 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -650,7 +650,7 @@ then
 	if test -z "$quiet"
 	then
 		echo "Created${initial_commit:+ initial} commit $commit"
-		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
+		git-diff-tree --shortstat --pretty=short --summary --root HEAD --
 	fi
 fi
 
-- 
MST
Michael S. Tsirkin· Apr 15, 2007, 22:39 UTC · re: Junio C Hamano · lore

[PATCH] display shortlog after git-commit

Display the subject of the commit just made.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display shortlog after git-commit
> 
> Too noisy for a default.
So maybe the following isn't too bad?
This results in:
$ ./git-commit.sh --amend
Created commit 5633ddde0e35210f607bde063bcbf709e4d20a8d
Display the subject of the commit just made.
 1 files changed, 1 insertions(+), 1 deletions(-)
Show changes to git-commit.sh +1 −1
diff --git a/git-commit.sh b/git-commit.sh
index 9e0959a..b2b90f0 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -650,7 +650,7 @@ then
 	if test -z "$quiet"
 	then
 		echo "Created${initial_commit:+ initial} commit $commit"
-		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
+		git-diff-tree --shortstat --pretty="format:%s" --summary --root --no-commit-id HEAD --
 	fi
 fi
 
-- 
MST
Junio C Hamano· Apr 15, 2007, 23:08 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> Display the subject of the commit just made.
WHY?  You just made the commit.
Show 11 quoted lines
>> Quoting Junio C Hamano <junkio@cox.net>:
>> Subject: Re: [PATCH] display shortlog after git-commit
>> 
>> Too noisy for a default.
>
> So maybe the following isn't too bad?
> This results in:
> $ ./git-commit.sh --amend
> Created commit 5633ddde0e35210f607bde063bcbf709e4d20a8d
> Display the subject of the commit just made.
>  1 files changed, 1 insertions(+), 1 deletions(-)

I think this is still one line too many. It _might_ be an improvement if it were

    $ ./git-commit.sh --amend
    Created commit 5633ddde: Display the subject of the commit just made.
     1 files changed, 1 insertions(+), 1 deletions(-)
though...
Michael S. Tsirkin· Apr 16, 2007, 03:53 UTC · re: Junio C Hamano · lore

[PATCH] display the subject of the commit just made

Useful e.g. to figure out what I did from screen history, or to make sure subject line is short enough and makes sense on its own.

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
> WHY?  You just made the commit.

Hopefully answered above. This also gets rid of the only user of --no-commit-id, so we should be able to deprecate this in the future in favor of --pretty=format:

Show 20 quoted lines
> >> Quoting Junio C Hamano <junkio@cox.net>:
> >> Subject: Re: [PATCH] display shortlog after git-commit
> >> 
> >> Too noisy for a default.
> >
> > So maybe the following isn't too bad?
> > This results in:
> > $ ./git-commit.sh --amend
> > Created commit 5633ddde0e35210f607bde063bcbf709e4d20a8d
> > Display the subject of the commit just made.
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> I think this is still one line too many.  It _might_ be an
> improvement if it were
> 
>     $ ./git-commit.sh --amend
>     Created commit 5633ddde: Display the subject of the commit just made.
>      1 files changed, 1 insertions(+), 1 deletions(-)
> 
> though...
Better?
Show changes to git-commit.sh +2 −1
diff --git a/git-commit.sh b/git-commit.sh
index 9e0959a..32257b0 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -649,8 +649,9 @@ then
 	fi
 	if test -z "$quiet"
 	then
+		commit=`git-diff-tree --shortstat --pretty="format:%h: %s"\
+		       --summary --root HEAD --`
 		echo "Created${initial_commit:+ initial} commit $commit"
-		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
 	fi
 fi
 
 
-- 
MST
Junio C Hamano· Apr 16, 2007, 05:16 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display the subject of the commit just made

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 16 quoted lines
> Better?
>
> diff --git a/git-commit.sh b/git-commit.sh
> index 9e0959a..32257b0 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -649,8 +649,9 @@ then
>  	fi
>  	if test -z "$quiet"
>  	then
> +		commit=`git-diff-tree --shortstat --pretty="format:%h: %s"\
> +		       --summary --root HEAD --`
>  		echo "Created${initial_commit:+ initial} commit $commit"
> -		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
>  	fi
>  fi
Close but no cigar.  You broke it for a merge commit, I think.
Perhaps
	pretty="format:Created${initial_commit:+ initial} commit %h: %s%n"
	git-diff-tree --always --shortstart --summary --root --pretty="$pretty" HEAD
Michael S. Tsirkin· Apr 16, 2007, 05:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] display the subject of the commit just made

Show 23 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display the subject of the commit just made
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> > Better?
> >
> > diff --git a/git-commit.sh b/git-commit.sh
> > index 9e0959a..32257b0 100755
> > --- a/git-commit.sh
> > +++ b/git-commit.sh
> > @@ -649,8 +649,9 @@ then
> >  	fi
> >  	if test -z "$quiet"
> >  	then
> > +		commit=`git-diff-tree --shortstat --pretty="format:%h: %s"\
> > +		       --summary --root HEAD --`
> >  		echo "Created${initial_commit:+ initial} commit $commit"
> > -		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
> >  	fi
> >  fi
> 
> Close but no cigar.  You broke it for a merge commit, I think.
Yes, you are right.
> Perhaps
> 
> 	pretty="format:Created${initial_commit:+ initial} commit %h: %s%n"
> 	git-diff-tree --always --shortstart --summary --root --pretty="$pretty" HEAD
Aha, --always should do the trick. I'll check this.
BTW, a couple of questions:
1. do we really need the shortstat info?
2. why is there "--" at the end do in the original version?
-- 
MST
Junio C Hamano· Apr 16, 2007, 06:17 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display the subject of the commit just made

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> BTW, a couple of questions:
> 1. do we really need the shortstat info?

I am between neutral to slightly negative, so I won't miss it if it is removed, but I'll let people who wanted it to defend it.

> 2. why is there "--" at the end do in the original version?
Blame is always your friend.
	$ git blame -L'/^git-diff-tree .*--$/,1' git-commit.sh
finds that it came from this commit:
commit 521f9c4def9430526bfdfffdb8ed4c2f4166bece
Author: Michael Loeffler <zvpunry@zvpunry.de>
Date:   Mon Jan 8 20:23:13 2007 +0100
    git-commit: do not fail to print the diffstat even if there is a file named HEAD
    
    Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Show changes to git-commit.sh +1 −1
diff --git a/git-commit.sh b/git-commit.sh
index 04aad5e..c2beb76 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -628,7 +628,7 @@ then
 	if test -z "$quiet"
 	then
 		echo "Created${initial_commit:+ initial} commit $commit"
-		git-diff-tree --shortstat --summary --root --no-commit-id HEAD
+		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
 	fi
 fi
Michael S. Tsirkin· Apr 16, 2007, 05:51 UTC · re: Junio C Hamano · lore

Re: [PATCH] display the subject of the commit just made

Display the subject of the commit just made.

Useful e.g. to figure out what I did from screen history, or to make sure subject line is short enough and makes sense on its own.

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Show 7 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Close but no cigar.  You broke it for a merge commit, I think.
> 
> Perhaps
> 
> 	pretty="format:Created${initial_commit:+ initial} commit %h: %s%n"
> 	git-diff-tree --always --shortstart --summary --root --pretty="$pretty" HEAD

OK, thanks fo rpointing this out. But why the extra %n at the end? The following seems to work well for me:

Show changes to git-commit.sh +2 −1
diff --git a/git-commit.sh b/git-commit.sh
index 9e0959a..f28fc24 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -649,8 +649,9 @@ then
 	fi
 	if test -z "$quiet"
 	then
+		commit=`git-diff-tree --always --shortstat --pretty="format:%h: %s"\
+		       --summary --root HEAD --`
 		echo "Created${initial_commit:+ initial} commit $commit"
-		git-diff-tree --shortstat --summary --root --no-commit-id HEAD --
 	fi
 fi
 
-- 
MST
Junio C Hamano· Apr 16, 2007, 06:01 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display the subject of the commit just made

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 20 quoted lines
> Display the subject of the commit just made.
>
> Useful e.g. to figure out what I did from screen history,
> or to make sure subject line is short enough and makes sense
> on its own.
>
> Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
>
> ---
>
>> Quoting Junio C Hamano <junkio@cox.net>:
>> Close but no cigar.  You broke it for a merge commit, I think.
>> 
>> Perhaps
>> 
>> 	pretty="format:Created${initial_commit:+ initial} commit %h: %s%n"
>> 	git-diff-tree --always --shortstart --summary --root --pretty="$pretty" HEAD
>
> OK, thanks fo rpointing this out.
> But why the extra %n at the end?
Because I *got* *rid* *of* "echo".
Michael S. Tsirkin· Apr 16, 2007, 06:18 UTC · re: Junio C Hamano · lore

Re: [PATCH] display the subject of the commit just made

Show 27 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display the subject of the commit just made
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> > Display the subject of the commit just made.
> >
> > Useful e.g. to figure out what I did from screen history,
> > or to make sure subject line is short enough and makes sense
> > on its own.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
> >
> > ---
> >
> >> Quoting Junio C Hamano <junkio@cox.net>:
> >> Close but no cigar.  You broke it for a merge commit, I think.
> >> 
> >> Perhaps
> >> 
> >> 	pretty="format:Created${initial_commit:+ initial} commit %h: %s%n"
> >> 	git-diff-tree --always --shortstart --summary --root --pretty="$pretty" HEAD
> >
> > OK, thanks fo rpointing this out.
> > But why the extra %n at the end?
> 
> Because I *got* *rid* *of* "echo".

Oh. But, this seems to stick an extra newline before the shortstart summary, instead of at the end. No?

 ./git-commit.sh --amend
Created commit 63cfb8c: test more
 1 files changed, 1 insertions(+), 1 deletions(-)
while in my version
 ./git-commit.sh --amend
Created commit 63cfb8c: test more
 1 files changed, 1 insertions(+), 1 deletions(-)
so I think we are stuck with echo.
-- 
MST
Junio C Hamano· Apr 16, 2007, 07:00 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display the subject of the commit just made

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 6 quoted lines
> Quoting Michael S. Tsirkin <mst@dev.mellanox.co.il>:
>> > Because I *got* *rid* *of* "echo".
>> 
>> so I think we are stuck with echo.
>
> So ... is it good to go?

I am not quite convinced that giving a short summary is necessary yet, probably for the same reason you questioned why we do --shortstat.

Shawn O. Pearce· Apr 16, 2007, 07:11 UTC · re: Junio C Hamano · lore

Re: [PATCH] display the subject of the commit just made

Junio C Hamano <junkio@cox.net> wrote:
Show 12 quoted lines
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> > Quoting Michael S. Tsirkin <mst@dev.mellanox.co.il>:
> >> > Because I *got* *rid* *of* "echo".
> >> 
> >> so I think we are stuck with echo.
> >
> > So ... is it good to go?
> 
> I am not quite convinced that giving a short summary is
> necessary yet, probably for the same reason you questioned why
> we do --shortstat.
Its not really necessary, no.

But when you have 8 terminal windows open, and you haven't looked at one in a while, and it has a nice output from current git-reset showing the subject of the commit you just reset to, that's handy to jog your memory about what the shell was doing before it got shuffled off the desk.

Now look at a git-commit output and find that's missing. If its cheap (and it is, reasonably so) it may be useful to some people.

Of course I'm one of those "gah, I got more shells than I know what I'm doing with!" people. ;-)

-- 
Shawn.
Alex Riesen· Apr 16, 2007, 12:56 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] display the subject of the commit just made

On 4/16/07, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 7 quoted lines
> > I am not quite convinced that giving a short summary is
> > necessary yet, probably for the same reason you questioned why
> > we do --shortstat.
>
> Of course I'm one of those "gah, I got more shells than I know what
> I'm doing with!" people.  ;-)
>
Me too. Please, can we have it? :)
Junio C Hamano· Apr 16, 2007, 17:46 UTC · re: Alex Riesen · lore

Re: [PATCH] display the subject of the commit just made

"Alex Riesen" <raa.lkml@gmail.com> writes:
Show 10 quoted lines
> On 4/16/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > I am not quite convinced that giving a short summary is
>> > necessary yet, probably for the same reason you questioned why
>> > we do --shortstat.
>>
>> Of course I'm one of those "gah, I got more shells than I know what
>> I'm doing with!" people.  ;-)
>>
>
> Me too. Please, can we have it? :)
Will be in.  And --shortstat is not going away.
Michael S. Tsirkin· Apr 16, 2007, 05:34 UTC · re: Junio C Hamano · lore

Re: [PATCH] display shortlog after git-commit

Show 8 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display shortlog after git-commit
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> > Display the subject of the commit just made.
> 
> WHY?  You just made the commit.

BTW, Junio, why does git-commit need to display the diffstat? You just made the commit ...

-- 
MST
Junio C Hamano· Apr 16, 2007, 06:04 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 11 quoted lines
>> Quoting Junio C Hamano <junkio@cox.net>:
>> Subject: Re: [PATCH] display shortlog after git-commit
>> 
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 
>> > Display the subject of the commit just made.
>> 
>> WHY?  You just made the commit.
>
> BTW, Junio, why does git-commit need to display the diffstat?
> You just made the commit ...
Don't ask me.  It was not my idea.

We only had --summary per popular list request, and it made certain amount of sense since addition/deletion are notable events that do not happen with _every_ commit.

Michael S. Tsirkin· Apr 16, 2007, 06:26 UTC · re: Junio C Hamano · lore

Re: [PATCH] display shortlog after git-commit

Show 22 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display shortlog after git-commit
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> >> Quoting Junio C Hamano <junkio@cox.net>:
> >> Subject: Re: [PATCH] display shortlog after git-commit
> >> 
> >> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> >> 
> >> > Display the subject of the commit just made.
> >> 
> >> WHY?  You just made the commit.
> >
> > BTW, Junio, why does git-commit need to display the diffstat?
> > You just made the commit ...
> 
> Don't ask me.  It was not my idea.
> 
> We only had --summary per popular list request, and it made
> certain amount of sense since addition/deletion are notable
> events that do not happen with _every_ commit.
Hmm. I agree. Does it make sense to only show additions/deletions?

Digging through git-commit.sh history, I found this: the log actually misleadingly talks about the summary of created/deleted files. Is it possible that git-runstatus --shortlog reported just the created/deleted files originally?

commit ebd124c6783da5e064963611ee17741cd173f6b5
Author: Nicolas Pitre <nico@cam.org>
Date:   Thu Dec 14 23:15:44 2006 -0500
    make commit message a little more consistent and conforting
    It is nicer to let the user know when a commit succeeded all the time,
    not only the first time.  Also the commit sha1 is much more useful than
    the tree sha1 in this case.
    This patch also introduces a -q switch to supress this message as well
    as the summary of created/deleted files.
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>

If yes, then is it possible that this change might have been introduced inadvetently by git-runstatus behaviour change?

Nicolas, what was the intent?
-- 
MST
Michael S. Tsirkin· Apr 16, 2007, 14:40 UTC · re: Junio C Hamano · lore

[PATCH] remove shortlog from git-commit output

Make git-commit only display --summary since addition/deletion are notable events that do not happen with every commit.

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Show 8 quoted lines
> > BTW, Junio, why does git-commit need to display the diffstat?
> > You just made the commit ...
> 
> Don't ask me.  It was not my idea.
> 
> We only had --summary per popular list request, and it made
> certain amount of sense since addition/deletion are notable
> events that do not happen with _every_ commit.
So how about this?
Show changes to git-commit.sh +1 −1
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..3e6866c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -649,7 +649,7 @@ then
 	fi
 	if test -z "$quiet"
 	then
-		commit=`git-diff-tree --always --shortstat --pretty="format:%h: %s"\
+		commit=`git-diff-tree --always --pretty="format:%h: %s"\
 		       --summary --root HEAD --`
 		echo "Created${initial_commit:+ initial} commit $commit"
 	fi
-- 
MST
Julian Phillips· Apr 16, 2007, 15:02 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] remove shortlog from git-commit output

On Mon, 16 Apr 2007, Michael S. Tsirkin wrote:
Show 18 quoted lines
> Make git-commit only display --summary since addition/deletion
> are notable events that do not happen with every commit.
>
> Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
>
> ---
>
>>> BTW, Junio, why does git-commit need to display the diffstat?
>>> You just made the commit ...
>>
>> Don't ask me.  It was not my idea.
>>
>> We only had --summary per popular list request, and it made
>> certain amount of sense since addition/deletion are notable
>> events that do not happen with _every_ commit.
>
> So how about this?
>

Personally I quite like the shortstat ... and certainly is/will be more useful to me than having the commit subject - despite normally having more terminals lying around than is good for my sanity.

Can't we keep it? It's not like it takes up much space ...
-- 
Julian

  ---
BOFH Excuse #134:

because of network lag due to too many people playing deathmatch
Michael S. Tsirkin· Apr 16, 2007, 18:23 UTC · re: Julian Phillips · lore

Re: [PATCH] remove shortlog from git-commit output

Show 29 quoted lines
> Quoting Julian Phillips <julian@quantumfyre.co.uk>:
> Subject: Re: [PATCH] remove shortlog from git-commit output
> 
> On Mon, 16 Apr 2007, Michael S. Tsirkin wrote:
> 
> >Make git-commit only display --summary since addition/deletion
> >are notable events that do not happen with every commit.
> >
> >Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
> >
> >---
> >
> >>>BTW, Junio, why does git-commit need to display the diffstat?
> >>>You just made the commit ...
> >>
> >>Don't ask me.  It was not my idea.
> >>
> >>We only had --summary per popular list request, and it made
> >>certain amount of sense since addition/deletion are notable
> >>events that do not happen with _every_ commit.
> >
> >So how about this?
> >
> 
> Personally I quite like the shortstat ... and certainly is/will be more 
> useful to me than having the commit subject - despite normally having more 
> terminals lying around than is good for my sanity.
> 
> Can't we keep it? It's not like it takes up much space ...

What's it used for? Would it make more sense to have it show up in the commit log editor, with the list of files being checked in?

-- 
MST
Julian Phillips· Apr 16, 2007, 20:21 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] remove shortlog from git-commit output

On Mon, 16 Apr 2007, Michael S. Tsirkin wrote:
Show 33 quoted lines
>> Quoting Julian Phillips <julian@quantumfyre.co.uk>:
>> Subject: Re: [PATCH] remove shortlog from git-commit output
>>
>> On Mon, 16 Apr 2007, Michael S. Tsirkin wrote:
>>
>>> Make git-commit only display --summary since addition/deletion
>>> are notable events that do not happen with every commit.
>>>
>>> Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
>>>
>>> ---
>>>
>>>>> BTW, Junio, why does git-commit need to display the diffstat?
>>>>> You just made the commit ...
>>>>
>>>> Don't ask me.  It was not my idea.
>>>>
>>>> We only had --summary per popular list request, and it made
>>>> certain amount of sense since addition/deletion are notable
>>>> events that do not happen with _every_ commit.
>>>
>>> So how about this?
>>>
>>
>> Personally I quite like the shortstat ... and certainly is/will be more
>> useful to me than having the commit subject - despite normally having more
>> terminals lying around than is good for my sanity.
>>
>> Can't we keep it? It's not like it takes up much space ...
>
> What's it used for? Would it make more sense to have it show
> up in the commit log editor, with the list of files being checked in?
>

I use git add -i quite a lot, so often the same file shows up in both the files that are being committed and in the list of files that have uncomitted changes. The shortstat gives me confidence that the commit was about the right size.

-- 
Julian

  ---
Uh-oh!!  I forgot to submit to COMPULSORY URINALYSIS!
Michael S. Tsirkin· Apr 17, 2007, 06:02 UTC · re: Julian Phillips · lore

Re: [PATCH] remove shortlog from git-commit output

Show 43 quoted lines
> Quoting Julian Phillips <julian@quantumfyre.co.uk>:
> Subject: Re: [PATCH] remove shortlog from git-commit output
> 
> On Mon, 16 Apr 2007, Michael S. Tsirkin wrote:
> 
> >>Quoting Julian Phillips <julian@quantumfyre.co.uk>:
> >>Subject: Re: [PATCH] remove shortlog from git-commit output
> >>
> >>On Mon, 16 Apr 2007, Michael S. Tsirkin wrote:
> >>
> >>>Make git-commit only display --summary since addition/deletion
> >>>are notable events that do not happen with every commit.
> >>>
> >>>Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
> >>>
> >>>---
> >>>
> >>>>>BTW, Junio, why does git-commit need to display the diffstat?
> >>>>>You just made the commit ...
> >>>>
> >>>>Don't ask me.  It was not my idea.
> >>>>
> >>>>We only had --summary per popular list request, and it made
> >>>>certain amount of sense since addition/deletion are notable
> >>>>events that do not happen with _every_ commit.
> >>>
> >>>So how about this?
> >>>
> >>
> >>Personally I quite like the shortstat ... and certainly is/will be more
> >>useful to me than having the commit subject - despite normally having more
> >>terminals lying around than is good for my sanity.
> >>
> >>Can't we keep it? It's not like it takes up much space ...
> >
> >What's it used for? Would it make more sense to have it show
> >up in the commit log editor, with the list of files being checked in?
> >
> 
> I use git add -i quite a lot, so often the same file shows up in both the 
> files that are being committed and in the list of files that have 
> uncomitted changes.  The shortstat gives me confidence that the commit was 
> about the right size.

If so, it would make more sense to show the diffstat inside the editor, where it's not too late to cancel the commit.

Would it be better to show it before or after the list of files?
-- 
MST
Julian Phillips· Apr 17, 2007, 07:27 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] remove shortlog from git-commit output

On Tue, 17 Apr 2007, Michael S. Tsirkin wrote:
Show 7 quoted lines
>> I use git add -i quite a lot, so often the same file shows up in both the
>> files that are being committed and in the list of files that have
>> uncomitted changes.  The shortstat gives me confidence that the commit was
>> about the right size.
>
> If so, it would make more sense to show the diffstat inside
> the editor, where it's not too late to cancel the commit.
In git, it's not too late after running commit ... ;)
>
> Would it be better to show it before or after the list of files?

Well, the files to be committed are listed first, and untracked files last. Next to the files to be committed would seem more sensible.

-- 
Julian

  ---
Man's unique agony as a species consists in his perpetual conflict between
the desire to stand out and the need to blend in.
 		-- Sydney J. Harris
Junio C Hamano· Apr 4, 2007, 08:15 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 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.

Show 6 quoted lines
>> 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.
Show 5 quoted lines
>> 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 <au.thor@example.com>
        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.

Show changes to git-commit.sh +31 −1
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
 
Michael S. Tsirkin· Apr 15, 2007, 10:33 UTC · re: Junio C Hamano · lore

Re: [PATCH] display shortlog after git-commit

Show 26 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display shortlog after git-commit
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> >> 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.
> 
> >> 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.
> 
> >> 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?

Show 12 quoted lines
> 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.
Show 72 quoted lines
> 	----------------------------------------------------------------
> 	From: A U Thor <au.thor@example.com>
>         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
-- 
MST
Junio C Hamano· Apr 15, 2007, 19:57 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display shortlog after git-commit

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 13 quoted lines
>> 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.
>
>> 	----------------------------------------------------------------
>> 	From: A U Thor <au.thor@example.com>
>>      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.

Michael S. Tsirkin· Apr 15, 2007, 20:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] display shortlog after git-commit

Show 25 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [PATCH] display shortlog after git-commit
> 
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 
> >> 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.
> >
> >> 	----------------------------------------------------------------
> >> 	From: A U Thor <au.thor@example.com>
> >>      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
Andy Parkins· Apr 15, 2007, 20:26 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] display shortlog after git-commit

On Sunday 2007, April 15, Michael S. Tsirkin wrote:
Show 6 quoted lines
> 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
Michael S. Tsirkin· Apr 15, 2007, 20:34 UTC · re: Andy Parkins · lore

Re: [PATCH] display shortlog after git-commit

Show 21 quoted lines
> Quoting Andy Parkins <andyparkins@gmail.com>:
> Subject: Re: [PATCH] display shortlog after git-commit
> 
> 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.
Yes, I see how that would be useful with amends.
-- 
MST
Jeff King· Apr 4, 2007, 06:24 UTC · re: Michael S. Tsirkin · lore

[PATCH] wt-status: show author info if status.showauthor is set

Signed-off-by: Jeff King <peff@peff.net>
---
On Wed, Apr 04, 2007 at 09:02:13AM +0300, Michael S. Tsirkin wrote:
> - Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
>   commit message, and let the user edit them?

Personally I think it's just clutter, but hey, it's off by default. Of course what is the chance that you've turned on status.showauthor in your ~/.gitconfig, but you don't have your identity set up properly? :)

Junio, this is somewhat tongue in cheek, but if people like it, please take it.

 Documentation/config.txt |    5 +++++
 wt-status.c              |   10 ++++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)
Show changes to 2 files +15 −0

Documentation/config.txt, wt-status.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index cf1e040..189e703 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -537,6 +537,11 @@ showbranch.default::
 	The default set of branches for gitlink:git-show-branch[1].
 	See gitlink:git-show-branch[1].
 
+status.showauthor::
+	If set to true, the output of git-status and the template used
+	for git-commit will show the author's name and email address.
+	Defaults to false.
+
 tar.umask::
 	By default, gitlink:git-tar-tree[1] sets file and directories modes
 	to 0666 or 0777. While this is both useful and acceptable for projects
diff --git a/wt-status.c b/wt-status.c
index a055990..3c3510c 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -8,6 +8,7 @@
 #include "revision.h"
 #include "diffcore.h"
 
+int wt_status_show_author = 0;
 int wt_status_use_color = 0;
 static char wt_status_colors[][COLOR_MAXLEN] = {
 	"",         /* WT_STATUS_HEADER: normal */
@@ -317,6 +318,11 @@ void wt_status_print(struct wt_status *s)
 			"# %s%s", on_what, branch_name);
 	}
 
+	if (wt_status_show_author)
+		color_printf_ln(color(WT_STATUS_HEADER),
+				"# author: %s",
+				git_author_info(0));
+
 	if (s->is_initial) {
 		color_printf_ln(color(WT_STATUS_HEADER), "#");
 		color_printf_ln(color(WT_STATUS_HEADER), "# Initial commit");
@@ -356,5 +362,9 @@ int git_status_config(const char *k, const char *v)
 		int slot = parse_status_slot(k, 13);
 		color_parse(v, k, wt_status_colors[slot]);
 	}
+	if (!strcmp(k, "status.showauthor")) {
+		wt_status_show_author = 1;
+		return 0;
+	}
 	return git_default_config(k, v);
 }
-- 
1.5.1.rc3.671.gd125-dirty
Junio C Hamano· Apr 4, 2007, 06:32 UTC · re: Jeff King · lore

Re: [PATCH] wt-status: show author info if status.showauthor is set

Jeff King <peff@peff.net> writes:
Show 13 quoted lines
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On Wed, Apr 04, 2007 at 09:02:13AM +0300, Michael S. Tsirkin wrote:
>
>> - Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
>>   commit message, and let the user edit them?
>
> Personally I think it's just clutter, but hey, it's off by default. Of
> course what is the chance that you've turned on status.showauthor in
> your ~/.gitconfig, but you don't have your identity set up properly? :)
>
> Junio, this is somewhat tongue in cheek, but if people like it, please
> take it.

It may be t-i-c, but on the other hand it might make sense to make git-commit take notice and use it.

If we were to go that route, I suspect it should not be of form "# author: Who AmI <who.ami@example.com>".

Maybe the updated git-commit commit log message rule could be:
 * If the lines in the first paragraph all begin with "From: ",
   or "Date: " (you do not have to override all of them), they
   are used to override authorship information;
 * If this feature is used, "Subject: " should be among the
   lines in the first paragraph for consistency.
 * Otherwise we will continue doing what we always have been
   doing.
Michael S. Tsirkin· Apr 4, 2007, 06:49 UTC · re: Jeff King · lore

Re: [PATCH] wt-status: show author info if status.showauthor is set

Show 14 quoted lines
> Quoting Jeff King <peff@peff.net>:
> Subject: [PATCH] wt-status: show author info if status.showauthor is set
> 
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On Wed, Apr 04, 2007 at 09:02:13AM +0300, Michael S. Tsirkin wrote:
> 
> > - Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
> >   commit message, and let the user edit them?
> 
> Personally I think it's just clutter, but hey, it's off by default. Of
> course what is the chance that you've turned on status.showauthor in
> your ~/.gitconfig, but you don't have your identity set up properly? :)

The point is that *someone else* can have showauthor set up in .gitconfig, and then he'll be able to use git commit --amend to fix up the identity without using --author explicitly.

-- 
MST
Junio C Hamano· Apr 4, 2007, 06:52 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] wt-status: show author info if status.showauthor is set

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 7 quoted lines
>> Personally I think it's just clutter, but hey, it's off by default. Of
>> course what is the chance that you've turned on status.showauthor in
>> your ~/.gitconfig, but you don't have your identity set up properly? :)
>
> The point is that *someone else* can have showauthor set up in .gitconfig,
> and then he'll be able to use git commit --amend to fix up
> the identity without using --author explicitly.
For that you would need to update git-commit, I think.
Shawn O. Pearce· Apr 4, 2007, 06:55 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH] wt-status: show author info if status.showauthor is set

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> wrote:
Show 13 quoted lines
> > Quoting Jeff King <peff@peff.net>:
> > On Wed, Apr 04, 2007 at 09:02:13AM +0300, Michael S. Tsirkin wrote:
> > 
> > > - Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
> > >   commit message, and let the user edit them?
> > 
> > Personally I think it's just clutter, but hey, it's off by default. Of
> > course what is the chance that you've turned on status.showauthor in
> > your ~/.gitconfig, but you don't have your identity set up properly? :)
> 
> The point is that *someone else* can have showauthor set up in .gitconfig,
> and then he'll be able to use git commit --amend to fix up
> the identity without using --author explicitly.

Hmm. Actually I'd like to be able to set (or change) the author using a From: line, much like email headers. Especially in the case of git-commit --amend, as sometimes I make a new commit as myself, then realize *after* I've quit the editor that the patch really came from someone else, and I should record the right author.

And no, the patch wasn't really a patch. It was a set of files from the user that I manually copy in, then commit. Though I have to wonder why I keep doing that as said user also does use the same Git repository as me... and edits and commits other files on their own just fine... ;-)

-- 
Shawn.
Jakub Narebski· Apr 4, 2007, 13:28 UTC · re: Jeff King · lore

Re: [PATCH] wt-status: show author info if status.showauthor is set

Jeff King wrote:
Show 8 quoted lines
> On Wed, Apr 04, 2007 at 09:02:13AM +0300, Michael S. Tsirkin wrote:
> 
>> - Maybe put Author: (or From:? and maybe Subject:?) line in the pre-formatted
>>   commit message, and let the user edit them?
> 
> Personally I think it's just clutter, but hey, it's off by default. Of
> course what is the chance that you've turned on status.showauthor in
> your ~/.gitconfig, but you don't have your identity set up properly? :)
It can be turned on in /etc/gitconfig (and of course user.name cannot).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Jakub Narebski· Mar 23, 2007, 13:57 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Junio C Hamano wrote:
> +The commit message is formed by the title taken from the
> +"Subject: ", a blank line and the body of the message up to
> +where the patch begins.  Excess whitespaces at the end of the
> +lines are automatically stripped.

Does this mean that git-am cannot make a log message that doesn't follow git formatting commit message guidelines, namely short one-line description, then longer description and signoff? It means that you cannot get log message which starts with paragraph (no emty line after first line of commit message)?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
J. Bruce Fields· Mar 23, 2007, 13:59 UTC · re: Jakub Narebski · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

On Fri, Mar 23, 2007 at 02:57:38PM +0100, Jakub Narebski wrote:
Show 10 quoted lines
> Junio C Hamano wrote:
> 
> > +The commit message is formed by the title taken from the
> > +"Subject: ", a blank line and the body of the message up to
> > +where the patch begins.  Excess whitespaces at the end of the
> > +lines are automatically stripped.
> 
> Does this mean that git-am cannot make a log message that doesn't
> follow git formatting commit message guidelines, namely short one-line
> description, then longer description and signoff?
The input to git-am is email, not log messages.
--b.
Jakub Narebski· Mar 23, 2007, 14:23 UTC · re: J. Bruce Fields · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

J. Bruce Fields wrote:
Show 13 quoted lines
> On Fri, Mar 23, 2007 at 02:57:38PM +0100, Jakub Narebski wrote:
>> Junio C Hamano wrote:
>> 
>>> +The commit message is formed by the title taken from the
>>> +"Subject: ", a blank line and the body of the message up to
>>> +where the patch begins.  Excess whitespaces at the end of the
>>> +lines are automatically stripped.
>> 
>> Does this mean that git-am cannot make a log message that doesn't
>> follow git formatting commit message guidelines, namely short one-line
>> description, then longer description and signoff?
> 
> The input to git-am is email, not log messages.

But that means that commit message which doesn't have empty line after first line cannot be send via git-send-email + git-am without changes, not be subject to git-rebase (which uses git-am machinery unless invoked with --merge option) without changing commit message, isn't it?

-- 
Jakub Narebski
Poland
J. Bruce Fields· Mar 23, 2007, 15:33 UTC · re: Jakub Narebski · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

On Fri, Mar 23, 2007 at 03:23:55PM +0100, Jakub Narebski wrote:
Show 12 quoted lines
> J. Bruce Fields wrote:
> > On Fri, Mar 23, 2007 at 02:57:38PM +0100, Jakub Narebski wrote:
> >> Junio C Hamano wrote:
> >> 
> >>> +The commit message is formed by the title taken from the
> >>> +"Subject: ", a blank line and the body of the message up to
> >>> +where the patch begins.  Excess whitespaces at the end of the
> >>> +lines are automatically stripped.
> >> 
> >> Does this mean that git-am cannot make a log message that doesn't
> >> follow git formatting commit message guidelines, namely short one-line
> >> description, then longer description and signoff?
Oh, sorry, I see--I misread "make" for "take" in the above!
Show 7 quoted lines
> > 
> > The input to git-am is email, not log messages.
> 
> But that means that commit message which doesn't have empty line after
> first line cannot be send via git-send-email + git-am without changes,
> not be subject to git-rebase (which uses git-am machinery unless invoked
> with --merge option) without changing commit message, isn't it?
Yup.

Doesn't seem like a big deal to me. But then it'd also seem more sensible to me if git-rebase worked directly with the original commits rather than going through git-format-patch/git-am. Maybe what I want is a git-cherry-pick that will accept a range.

--b.
Jakub Narebski· Mar 24, 2007, 00:03 UTC · re: J. Bruce Fields · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

J. Bruce Fields wrote:
Show 16 quoted lines
> On Fri, Mar 23, 2007 at 03:23:55PM +0100, Jakub Narebski wrote:
>> J. Bruce Fields wrote:
>>> 
>>> The input to git-am is email, not log messages.
>> 
>> But that means that commit message which doesn't have empty line after
>> first line cannot be send via git-send-email + git-am without changes,
>> not be subject to git-rebase (which uses git-am machinery unless invoked
>> with --merge option) without changing commit message, isn't it?
> 
> Yup.
> 
> Doesn't seem like a big deal to me.  But then it'd also seem more
> sensible to me if git-rebase worked directly with the original commits
> rather than going through git-format-patch/git-am.  Maybe what I want is
> a git-cherry-pick that will accept a range.

git-rebase works directly with original commits if you use merge driven git-rebase, with --merge option (or -s <strategy> option, which implies --merge), which is present since Jun 21, 2006.

BTW. I do wonder if "git rebase --merge" accepts and honors -C<n> option...
-- 
Jakub Narebski
Poland
Michael S. Tsirkin· Mar 22, 2007, 09:07 UTC · re: Junio C Hamano · lore

[PATCH] Put FETCH_HEAD data in merge commit message

This makes git-fetch <URL> && git-merge FETCH_HEAD produce same merge message as git-pull <URL>

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Show 15 quoted lines
> To reiterate the more important points (this is also for my own
> purpose because I do not want the patch lost in this noise we
> are making):
> 
>  - Checking readability of $GIT_DIR/$remote itself is too loose;
>    the name FETCH_HEAD should explicitly be checked, as that is
>    the file that has the specific format that is understood by
>    fmt-merge-msg.
> 
>  - "echo -n" is to be avoided for portability.
> 
>  - "git fetch $URL foo bar" would leave two lines in FETCH_HEAD;
>    subsequent "git merge FETCH_HEAD" would merge only foo.  Pick
>    the first line, stripping out not-for-merge marker and let it
>    processed by fmt-merge-msg.
Is this OK?
Show changes to git-merge.sh +4 −0
diff --git a/git-merge.sh b/git-merge.sh
index 8759c5a..417bf33 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -108,6 +108,10 @@ merge_name () {
 		git-show-ref -q --verify "refs/heads/$truname" 2>/dev/null
 	then
 		echo "$rh		branch '$truname' (early part) of ."
+	elif test "$remote" = "FETCH_HEAD" -a -r "$GIT_DIR/FETCH_HEAD"
+	then
+		sed -e 's/	not-for-merge	/		/' -e 1q\
+	       		"$GIT_DIR/FETCH_HEAD"
 	else
 		echo "$rh		commit '$remote'"
 	fi
-- 
MST
Jeff King· Mar 22, 2007, 08:33 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

On Wed, Mar 21, 2007 at 08:37:07AM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> I often hear from people who seems to like "fetch & merge",
> instead of "pull & reset ORIG_HEAD", as a workflow to avoid
> undesirable merging.  This might largely be a matter of taste,
> but from philosophical point of view, fetch & merge is a sign of
> distrust (your default is not to merge, and you merge only when
> you choose to), and pull & reset is the opposite (your default
> is to merge, and after you inspect you may choose not to merge).
> Tool support to encourage the former feels somewhat wrong.

I don't think it necessarily means distrust; I always do a fetch + inspect + merge, and I am often fetching my own code to a different platform!

My reason is that the inspect step takes an arbitrary amount of time, and I don't want to lose my place. That is, I might go eat dinner in the middle of the 'inspect' and then come back. By using my branch head as a checkpoint, I am recording "I have inspected up to my master"; when I am done inspecting, the merge moves my checkpoint forward. That way I never fail to look over the commits; I don't do this out of distrust, but because I want to see all of the commits.

I could just use FETCH_HEAD, but it is easy to overwrite accidentally (if I do another git-fetch after dinner, not realizing I'm in the middle of an inspection already, or if I'm looking to grab more changes). I could also use the reflog, but it will also change if I fetch again in the middle.

Of course, I use this for small-ish projects like git, or personal projects. I don't think trying to glance over every commit to the kernel would be scalable.

-Peff
Junio C Hamano· Mar 22, 2007, 08:51 UTC · re: Jeff King · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

Jeff King <peff@peff.net> writes:
Show 9 quoted lines
> I don't think it necessarily means distrust; I always do a fetch +
> inspect + merge, and I am often fetching my own code to a different
> platform!
>
> My reason is that the inspect step takes an arbitrary amount of time,
> and I don't want to lose my place. That is, I might go eat dinner in the
> middle of the 'inspect' and then come back. By using my branch head as a
> checkpoint, I am recording "I have inspected up to my master"; when I am
> done inspecting, the merge moves my checkpoint forward.

Oh, I very much agree with you, but then I would just use another "inspection" branch, like:

	git checkout -b inspect-jeffs-work master
        git pull $jeff
        git log master..
        ... takes quite time.
        ... interrupted, goes back to work on _my_ master
        git checkout master
        ... does whatever
        git checkout inspect-jeffs-work
        ... continue
        ... looks good
        git checkout master
        git pull $jeff
        git log inspect-jeffs-work..master
	... things that jeff did since I inspected them on the branch
        ... If I do not like them ...
        git reset --hard HEAD^
The advantage is of course I can get interrupted at any time.
Jeff King· Mar 22, 2007, 09:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

On Thu, Mar 22, 2007 at 01:51:17AM -0700, Junio C Hamano wrote:
> Oh, I very much agree with you, but then I would just use
> another "inspection" branch, like:

That makes sense, though for somebody like me who is mostly _tracking_ development, I think it's a little simpler to just use master and origin.

-Peff
Andy Parkins· Mar 22, 2007, 09:10 UTC · re: Junio C Hamano · lore

Re: [PATCH] have merge put FETCH_HEAD data in commit message

On Wednesday 2007 March 21 15:37, Junio C Hamano wrote:
Show 8 quoted lines
> I often hear from people who seems to like "fetch & merge",
> instead of "pull & reset ORIG_HEAD", as a workflow to avoid
> undesirable merging.  This might largely be a matter of taste,
> but from philosophical point of view, fetch & merge is a sign of
> distrust (your default is not to merge, and you merge only when
> you choose to), and pull & reset is the opposite (your default
> is to merge, and after you inspect you may choose not to merge).
> Tool support to encourage the former feels somewhat wrong.

It's definitely not wrong - and I realise you aren't advocating removing fetch & merge; however I wanted to explain why fetch & merge isn't wrong. I almost never use pull; in fact, of the two work methods you mention, I can't see that git-pull would ever be the my regular use case (I wonder if I'm missing something and need enlightening?)

Use case (1)

A colleague and I work on the same project; with fundamentally the same code base. He commits to one branch and I commit to an other. I want to be able to see what he's doing, but definitely don't want to merge that branch. Regular git-fetch sorts that out. Occasionally, his branch stabilises to the point were we want to merge my changes in. I'm more familiar with both branches than him so it's better if I do the merge and resolve the conflicts. git-merge does that job.

Strangely enough, I've also found that it's better to resolve some commits before the merge is done. Using "git-diff mybranch hisbranch" often shows changes that are going to conflict, but don't need to - this is usually things like "// comment this block out while I'm testing something else".

Use case (2):

I keep branches around for submission to git. Whenever they're ready to go I rebase them on to master resolve conflicts and email them in. That is git-fetch, git-rebase. I have never run git-pull on my git repository.

Use case (3):

I'm tracking an upstream project that uses svn; git-svn makes light work of keeping up to date with it and keeping a "git-svn" branch to track it. I keep my own local changes to it - never for submission upstream - in a separate branch; infrequently I merge the upstream branch into my own.

Your favoured case misses out one significant step:
 * git-pull
 * Spend time resolving conflicts
 * git-reset ORIG_HEAD
It's not a sign of distrust that I don't do git-pull; I trust git to do a 
fantastic job when that moment comes.  However, it is a sign of laziness - 
why should I want to resolve conflicts just so they can be thrown away when I 
don't like them.
Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Michael S. Tsirkin· Mar 21, 2007, 17:29 UTC · re: Michael S. Tsirkin · lore

[PATCHv2] put FETCH_HEAD data in merge commit message

Show 20 quoted lines
> Quoting Michael S. Tsirkin <mst@dev.mellanox.co.il>:
> Subject: [PATCH] have merge put FETCH_HEAD data in commit message
> 
> Hi!
> I often like to fetch some code from others, review and
> then merge. So:
> 
> git fetch <URL>
> git log -p FETCH_HEAD
> git merge FETCH_HEAD
> 
> which is all good but gets me this message in commit log:
> 
>     Merge commit 'FETCH_HEAD' into master
> 
> which is not very informative.
> I can always fix this up with git commit --amend, but
> I'd like to avoid the extra step.
> 
> Would the following patch be appropriate?

OK, I since discovered git-fmt-merge-msg does all the necessary formatting, so here's a better and smaller patch. Seems to work well for me.

Junio, could you apply this?
-------------------------

Make git-fetch <URL> && git-merge FETCH_HEAD produce same merge message as git-pull <URL>

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Show changes to git-merge.sh +3 −0
diff --git a/git-merge.sh b/git-merge.sh
index 8759c5a..1e11593 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -108,6 +108,9 @@ merge_name () {
 		git-show-ref -q --verify "refs/heads/$truname" 2>/dev/null
 	then
 		echo "$rh		branch '$truname' (early part) of ."
+	elif test -r "$GIT_DIR/$remote"
+	then
+		cat "$GIT_DIR/$remote"
 	else
 		echo "$rh		commit '$remote'"
 	fi
-- 
MST
Junio C Hamano· Mar 21, 2007, 18:09 UTC · re: Michael S. Tsirkin · lore

Re: [PATCHv2] put FETCH_HEAD data in merge commit message

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
Show 25 quoted lines
>> Quoting Michael S. Tsirkin <mst@dev.mellanox.co.il>:
>> Subject: [PATCH] have merge put FETCH_HEAD data in commit message
>> 
>> Hi!
>> I often like to fetch some code from others, review and
>> then merge. So:
>> 
>> git fetch <URL>
>> git log -p FETCH_HEAD
>> git merge FETCH_HEAD
>> 
>> which is all good but gets me this message in commit log:
>> 
>>     Merge commit 'FETCH_HEAD' into master
>> 
>> which is not very informative.
>> I can always fix this up with git commit --amend, but
>> I'd like to avoid the extra step.
>> 
>> Would the following patch be appropriate?
>
> OK, I since discovered git-fmt-merge-msg does all the necessary formatting,
> so here's a better and smaller patch. Seems to work well for me.
>
> Junio, could you apply this?
I am afraid not.  You missed all the points I raised in my reply.

← back to recent threads