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

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 ...
[ message continues ]

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 ...
[ message continues ]

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
-

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.

-

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
-

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
-

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.

-

I know that's how git-am wants the input to look.

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

-- 
MST
-

Like SubmittingPatches?

-

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

-- 
MST
-

(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 onl...
[ message continues ]

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>


Is this OK?

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
-

Thanks.

-

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


Thanks, I'll try to address these.

-- 
MST
-

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(-)

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

-

It's funny ... but what should I look at there, specifically?

-- 
MST
-

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

It is an example that you can override Subject: (#4 above).

-

Quoting Junio C Hamano <junkio@cox.net>:

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?

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
-

Signed-off-by: Jeff King <peff@peff.net>
---

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(-)

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...
[ message continues ]

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
-

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

For that you would need to update git-commit, I think.

-

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.




-

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...
[ message continues ]

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>


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?

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
-

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

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.

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 "# P...
[ message continues ]

OK but [user] novice would have to be set by default then,

You are right. How about only doing this only if

 
-- 
MST
-

Too noisy for a default.


-

Display the subject of the commit just made.

Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>


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(-)

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
-

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

-

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

-- 
MST
-

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.


-

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>


So how about this?

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
-

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
-

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
-

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!
-

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
-

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
-

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
-

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>


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

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
 
 
-- 
MST
-

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

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

Right. Sorry.

-- 
MST
-