* [PATCH] have merge put FETCH_HEAD data in commit message
@ 2007-03-21 12:06 Michael S. Tsirkin
2007-03-21 15:37 ` Junio C Hamano
2007-03-21 17:29 ` [PATCHv2] put FETCH_HEAD data in merge " Michael S. Tsirkin
0 siblings, 2 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-21 12:06 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
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>
---
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-21 12:06 [PATCH] have merge put FETCH_HEAD data in commit message Michael S. Tsirkin
@ 2007-03-21 15:37 ` Junio C Hamano
2007-03-22 5:02 ` Michael S. Tsirkin
` (2 more replies)
2007-03-21 17:29 ` [PATCHv2] put FETCH_HEAD data in merge " Michael S. Tsirkin
1 sibling, 3 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-03-21 15:37 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> 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.
> 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
...
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCHv2] put FETCH_HEAD data in merge commit message
2007-03-21 12:06 [PATCH] have merge put FETCH_HEAD data in commit message Michael S. Tsirkin
2007-03-21 15:37 ` Junio C Hamano
@ 2007-03-21 17:29 ` Michael S. Tsirkin
2007-03-21 18:09 ` Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-21 17:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
> 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>
---
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCHv2] put FETCH_HEAD data in merge commit message
2007-03-21 17:29 ` [PATCHv2] put FETCH_HEAD data in merge " Michael S. Tsirkin
@ 2007-03-21 18:09 ` Junio C Hamano
0 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-03-21 18:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-21 15:37 ` Junio C Hamano
@ 2007-03-22 5:02 ` Michael S. Tsirkin
2007-03-22 5:09 ` Junio C Hamano
2007-03-22 8:33 ` [PATCH] have merge put FETCH_HEAD data in " Jeff King
2007-03-22 9:10 ` Andy Parkins
2 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-22 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 5:02 ` Michael S. Tsirkin
@ 2007-03-22 5:09 ` Junio C Hamano
2007-03-22 6:28 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-03-22 5:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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>
which is not too hard to follow.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 5:09 ` Junio C Hamano
@ 2007-03-22 6:28 ` Michael S. Tsirkin
2007-03-22 7:15 ` Junio C Hamano
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-22 6:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 6:28 ` Michael S. Tsirkin
@ 2007-03-22 7:15 ` Junio C Hamano
2007-03-22 7:41 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-03-22 7:15 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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?
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 7:15 ` Junio C Hamano
@ 2007-03-22 7:41 ` Michael S. Tsirkin
2007-03-22 8:21 ` Junio C Hamano
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-22 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 7:41 ` Michael S. Tsirkin
@ 2007-03-22 8:21 ` Junio C Hamano
2007-03-22 8:37 ` Michael S. Tsirkin
2007-03-22 9:07 ` [PATCH] Put FETCH_HEAD data in merge " Michael S. Tsirkin
0 siblings, 2 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-03-22 8:21 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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
>>
>> "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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-21 15:37 ` Junio C Hamano
2007-03-22 5:02 ` Michael S. Tsirkin
@ 2007-03-22 8:33 ` Jeff King
2007-03-22 8:51 ` Junio C Hamano
2007-03-22 9:10 ` Andy Parkins
2 siblings, 1 reply; 70+ messages in thread
From: Jeff King @ 2007-03-22 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
On Wed, Mar 21, 2007 at 08:37:07AM -0700, Junio C Hamano wrote:
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 8:21 ` Junio C Hamano
@ 2007-03-22 8:37 ` Michael S. Tsirkin
2007-03-22 10:31 ` Junio C Hamano
2007-03-22 9:07 ` [PATCH] Put FETCH_HEAD data in merge " Michael S. Tsirkin
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-22 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> (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)
> (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.
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 8:33 ` [PATCH] have merge put FETCH_HEAD data in " Jeff King
@ 2007-03-22 8:51 ` Junio C Hamano
2007-03-22 9:09 ` Jeff King
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-03-22 8:51 UTC (permalink / raw)
To: Jeff King; +Cc: Michael S. Tsirkin, Git Mailing List
Jeff King <peff@peff.net> writes:
> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] Put FETCH_HEAD data in merge commit message
2007-03-22 8:21 ` Junio C Hamano
2007-03-22 8:37 ` Michael S. Tsirkin
@ 2007-03-22 9:07 ` Michael S. Tsirkin
2007-03-22 10:01 ` Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-22 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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>
---
> 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?
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 8:51 ` Junio C Hamano
@ 2007-03-22 9:09 ` Jeff King
0 siblings, 0 replies; 70+ messages in thread
From: Jeff King @ 2007-03-22 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-21 15:37 ` Junio C Hamano
2007-03-22 5:02 ` Michael S. Tsirkin
2007-03-22 8:33 ` [PATCH] have merge put FETCH_HEAD data in " Jeff King
@ 2007-03-22 9:10 ` Andy Parkins
2 siblings, 0 replies; 70+ messages in thread
From: Andy Parkins @ 2007-03-22 9:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael S. Tsirkin
On Wednesday 2007 March 21 15:37, Junio C Hamano wrote:
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Put FETCH_HEAD data in merge commit message
2007-03-22 9:07 ` [PATCH] Put FETCH_HEAD data in merge " Michael S. Tsirkin
@ 2007-03-22 10:01 ` Junio C Hamano
0 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-03-22 10:01 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
Thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 8:37 ` Michael S. Tsirkin
@ 2007-03-22 10:31 ` Junio C Hamano
2007-03-22 10:40 ` Michael S. Tsirkin
2007-03-23 13:57 ` [PATCH] have merge put FETCH_HEAD data in commit message Jakub Narebski
0 siblings, 2 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-03-22 10:31 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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? 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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 10:31 ` Junio C Hamano
@ 2007-03-22 10:40 ` Michael S. Tsirkin
2007-03-24 10:21 ` Junio C Hamano
2007-03-23 13:57 ` [PATCH] have merge put FETCH_HEAD data in commit message Jakub Narebski
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-03-22 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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?
>
>
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 10:31 ` Junio C Hamano
2007-03-22 10:40 ` Michael S. Tsirkin
@ 2007-03-23 13:57 ` Jakub Narebski
2007-03-23 13:59 ` J. Bruce Fields
1 sibling, 1 reply; 70+ messages in thread
From: Jakub Narebski @ 2007-03-23 13:57 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-23 13:57 ` [PATCH] have merge put FETCH_HEAD data in commit message Jakub Narebski
@ 2007-03-23 13:59 ` J. Bruce Fields
2007-03-23 14:23 ` Jakub Narebski
0 siblings, 1 reply; 70+ messages in thread
From: J. Bruce Fields @ 2007-03-23 13:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
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.
--b.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-23 13:59 ` J. Bruce Fields
@ 2007-03-23 14:23 ` Jakub Narebski
2007-03-23 15:33 ` J. Bruce Fields
0 siblings, 1 reply; 70+ messages in thread
From: Jakub Narebski @ 2007-03-23 14:23 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
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?
>
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-23 14:23 ` Jakub Narebski
@ 2007-03-23 15:33 ` J. Bruce Fields
2007-03-24 0:03 ` Jakub Narebski
0 siblings, 1 reply; 70+ messages in thread
From: J. Bruce Fields @ 2007-03-23 15:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Fri, Mar 23, 2007 at 03:23:55PM +0100, Jakub Narebski wrote:
> 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!
> >
> > 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-23 15:33 ` J. Bruce Fields
@ 2007-03-24 0:03 ` Jakub Narebski
0 siblings, 0 replies; 70+ messages in thread
From: Jakub Narebski @ 2007-03-24 0:03 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
J. Bruce Fields wrote:
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-22 10:40 ` Michael S. Tsirkin
@ 2007-03-24 10:21 ` Junio C Hamano
2007-04-04 6:02 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-03-24 10:21 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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", 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.
>> 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).
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-03-24 10:21 ` Junio C Hamano
@ 2007-04-04 6:02 ` Michael S. Tsirkin
2007-04-04 6:09 ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-04 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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?
--
MST
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-04-04 6:02 ` Michael S. Tsirkin
@ 2007-04-04 6:09 ` Junio C Hamano
2007-04-04 6:18 ` Michael S. Tsirkin
2007-04-04 6:19 ` Shawn O. Pearce
2007-04-04 6:24 ` Junio C Hamano
2007-04-04 6:24 ` [PATCH] wt-status: show author info if status.showauthor is set Jeff King
2 siblings, 2 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 6:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 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*.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-04-04 6:09 ` Junio C Hamano
@ 2007-04-04 6:18 ` Michael S. Tsirkin
2007-04-04 6:19 ` Shawn O. Pearce
1 sibling, 0 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-04 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-04-04 6:09 ` Junio C Hamano
2007-04-04 6:18 ` Michael S. Tsirkin
@ 2007-04-04 6:19 ` Shawn O. Pearce
2007-04-04 6:25 ` Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Shawn O. Pearce @ 2007-04-04 6:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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... ;-)
--
Shawn.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-04-04 6:02 ` Michael S. Tsirkin
2007-04-04 6:09 ` Junio C Hamano
@ 2007-04-04 6:24 ` Junio C Hamano
2007-04-04 7:01 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
2007-04-04 6:24 ` [PATCH] wt-status: show author info if status.showauthor is set Jeff King
2 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 6:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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
>
>> "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/...
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] wt-status: show author info if status.showauthor is set
2007-04-04 6:02 ` Michael S. Tsirkin
2007-04-04 6:09 ` Junio C Hamano
2007-04-04 6:24 ` Junio C Hamano
@ 2007-04-04 6:24 ` Jeff King
2007-04-04 6:32 ` Junio C Hamano
` (2 more replies)
2 siblings, 3 replies; 70+ messages in thread
From: Jeff King @ 2007-04-04 6:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
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(-)
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-04-04 6:19 ` Shawn O. Pearce
@ 2007-04-04 6:25 ` Junio C Hamano
2007-04-04 6:35 ` Shawn O. Pearce
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 6:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michael S. Tsirkin, Git Mailing List
"Shawn O. Pearce" <spearce@spearce.org> writes:
> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] wt-status: show author info if status.showauthor is set
2007-04-04 6:24 ` [PATCH] wt-status: show author info if status.showauthor is set Jeff King
@ 2007-04-04 6:32 ` Junio C Hamano
2007-04-04 6:49 ` Michael S. Tsirkin
2007-04-04 13:28 ` Jakub Narebski
2 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 6:32 UTC (permalink / raw)
To: Jeff King; +Cc: Michael S. Tsirkin, Git Mailing List
Jeff King <peff@peff.net> writes:
> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] have merge put FETCH_HEAD data in commit message
2007-04-04 6:25 ` Junio C Hamano
@ 2007-04-04 6:35 ` Shawn O. Pearce
0 siblings, 0 replies; 70+ messages in thread
From: Shawn O. Pearce @ 2007-04-04 6:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
Junio C Hamano <junkio@cox.net> wrote:
> "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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] wt-status: show author info if status.showauthor is set
2007-04-04 6:24 ` [PATCH] wt-status: show author info if status.showauthor is set Jeff King
2007-04-04 6:32 ` Junio C Hamano
@ 2007-04-04 6:49 ` Michael S. Tsirkin
2007-04-04 6:52 ` Junio C Hamano
2007-04-04 6:55 ` Shawn O. Pearce
2007-04-04 13:28 ` Jakub Narebski
2 siblings, 2 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-04 6:49 UTC (permalink / raw)
To: Jeff King; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] wt-status: show author info if status.showauthor is set
2007-04-04 6:49 ` Michael S. Tsirkin
@ 2007-04-04 6:52 ` Junio C Hamano
2007-04-04 6:55 ` Shawn O. Pearce
1 sibling, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 6:52 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jeff King, Git Mailing List
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] wt-status: show author info if status.showauthor is set
2007-04-04 6:49 ` Michael S. Tsirkin
2007-04-04 6:52 ` Junio C Hamano
@ 2007-04-04 6:55 ` Shawn O. Pearce
1 sibling, 0 replies; 70+ messages in thread
From: Shawn O. Pearce @ 2007-04-04 6:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jeff King, Junio C Hamano, Git Mailing List
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> wrote:
> > 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] display shortlog after git-commit
2007-04-04 6:24 ` Junio C Hamano
@ 2007-04-04 7:01 ` Michael S. Tsirkin
2007-04-04 7:22 ` Junio C Hamano
2007-04-04 8:15 ` [PATCH] display shortlog after git-commit Junio C Hamano
0 siblings, 2 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-04 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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>
---
> 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?
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-04 7:01 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
@ 2007-04-04 7:22 ` Junio C Hamano
2007-04-15 22:39 ` Michael S. Tsirkin
2007-04-04 8:15 ` [PATCH] display shortlog after git-commit Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 7:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
Too noisy for a default.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-04 7:01 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
2007-04-04 7:22 ` Junio C Hamano
@ 2007-04-04 8:15 ` Junio C Hamano
2007-04-15 10:33 ` Michael S. Tsirkin
1 sibling, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-04 8:15 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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?
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 "# 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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] wt-status: show author info if status.showauthor is set
2007-04-04 6:24 ` [PATCH] wt-status: show author info if status.showauthor is set Jeff King
2007-04-04 6:32 ` Junio C Hamano
2007-04-04 6:49 ` Michael S. Tsirkin
@ 2007-04-04 13:28 ` Jakub Narebski
2 siblings, 0 replies; 70+ messages in thread
From: Jakub Narebski @ 2007-04-04 13:28 UTC (permalink / raw)
To: git
Jeff King wrote:
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-04 8:15 ` [PATCH] display shortlog after git-commit Junio C Hamano
@ 2007-04-15 10:33 ` Michael S. Tsirkin
2007-04-15 19:57 ` Junio C Hamano
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-15 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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?
> 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.
> ----------------------------------------------------------------
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-15 10:33 ` Michael S. Tsirkin
@ 2007-04-15 19:57 ` Junio C Hamano
2007-04-15 20:09 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-15 19:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-15 19:57 ` Junio C Hamano
@ 2007-04-15 20:09 ` Michael S. Tsirkin
2007-04-15 20:26 ` Andy Parkins
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-15 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-15 20:09 ` Michael S. Tsirkin
@ 2007-04-15 20:26 ` Andy Parkins
2007-04-15 20:34 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Andy Parkins @ 2007-04-15 20:26 UTC (permalink / raw)
To: git, Michael S. Tsirkin; +Cc: Junio C Hamano
On Sunday 2007, April 15, Michael S. Tsirkin wrote:
> And I wander why does it tell me the new commit hash -
> wouldn't displaying the subject make more sense?
> Something like
>
> Created commit "Make foobar faster by caching more barbar in foo"
> 1 files changed, 1 insertions(+), 0 deletions(-)
If you do a series of "git commit --amend"s, you would get an identical
message each time. Also, I've often found it convenient when doing
resets, amends, patch splits and movements between branches to be able
to cut and paste the commit hash still on the terminal into lines like
git commit --amend -c $HASH
I wouldn't object to having the subject as well, but please don't lose
the hash - it's very useful.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-15 20:26 ` Andy Parkins
@ 2007-04-15 20:34 ` Michael S. Tsirkin
0 siblings, 0 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-15 20:34 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Michael S. Tsirkin, Junio C Hamano
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] display shortlog after git-commit
2007-04-04 7:22 ` Junio C Hamano
@ 2007-04-15 22:39 ` Michael S. Tsirkin
2007-04-15 23:08 ` Junio C Hamano
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-15 22:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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(-)
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-15 22:39 ` Michael S. Tsirkin
@ 2007-04-15 23:08 ` Junio C Hamano
2007-04-16 3:53 ` [PATCH] display the subject of the commit just made Michael S. Tsirkin
2007-04-16 5:34 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
0 siblings, 2 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-15 23:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> Display the subject of the commit just made.
WHY? You just made the commit.
>> 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...
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] display the subject of the commit just made
2007-04-15 23:08 ` Junio C Hamano
@ 2007-04-16 3:53 ` Michael S. Tsirkin
2007-04-16 5:16 ` Junio C Hamano
2007-04-16 5:34 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 3:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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:
> >> 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?
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 3:53 ` [PATCH] display the subject of the commit just made Michael S. Tsirkin
@ 2007-04-16 5:16 ` Junio C Hamano
2007-04-16 5:40 ` Michael S. Tsirkin
2007-04-16 5:51 ` Michael S. Tsirkin
0 siblings, 2 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-16 5:16 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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.
Perhaps
pretty="format:Created${initial_commit:+ initial} commit %h: %s%n"
git-diff-tree --always --shortstart --summary --root --pretty="$pretty" HEAD
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-15 23:08 ` Junio C Hamano
2007-04-16 3:53 ` [PATCH] display the subject of the commit just made Michael S. Tsirkin
@ 2007-04-16 5:34 ` Michael S. Tsirkin
2007-04-16 6:04 ` Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 5:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 5:16 ` Junio C Hamano
@ 2007-04-16 5:40 ` Michael S. Tsirkin
2007-04-16 6:17 ` Junio C Hamano
2007-04-16 5:51 ` Michael S. Tsirkin
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 5:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 5:16 ` Junio C Hamano
2007-04-16 5:40 ` Michael S. Tsirkin
@ 2007-04-16 5:51 ` Michael S. Tsirkin
2007-04-16 6:01 ` Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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? The following seems to work well for me:
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 5:51 ` Michael S. Tsirkin
@ 2007-04-16 6:01 ` Junio C Hamano
2007-04-16 6:18 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-16 6:01 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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".
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-16 5:34 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
@ 2007-04-16 6:04 ` Junio C Hamano
2007-04-16 6:26 ` Michael S. Tsirkin
2007-04-16 14:40 ` [PATCH] remove shortlog from git-commit output Michael S. Tsirkin
0 siblings, 2 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-16 6:04 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 5:40 ` Michael S. Tsirkin
@ 2007-04-16 6:17 ` Junio C Hamano
0 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-16 6:17 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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>
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 6:01 ` Junio C Hamano
@ 2007-04-16 6:18 ` Michael S. Tsirkin
2007-04-16 6:51 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display shortlog after git-commit
2007-04-16 6:04 ` Junio C Hamano
@ 2007-04-16 6:26 ` Michael S. Tsirkin
2007-04-16 14:40 ` [PATCH] remove shortlog from git-commit output Michael S. Tsirkin
1 sibling, 0 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List, Nicolas Pitre
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 6:18 ` Michael S. Tsirkin
@ 2007-04-16 6:51 ` Michael S. Tsirkin
2007-04-16 7:00 ` Junio C Hamano
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 6:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
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?
--
MST
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 6:51 ` Michael S. Tsirkin
@ 2007-04-16 7:00 ` Junio C Hamano
2007-04-16 7:11 ` Shawn O. Pearce
0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2007-04-16 7:00 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Git Mailing List
"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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 7:00 ` Junio C Hamano
@ 2007-04-16 7:11 ` Shawn O. Pearce
2007-04-16 7:59 ` Michael S. Tsirkin
2007-04-16 12:56 ` Alex Riesen
0 siblings, 2 replies; 70+ messages in thread
From: Shawn O. Pearce @ 2007-04-16 7:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
Junio C Hamano <junkio@cox.net> wrote:
> "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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 7:11 ` Shawn O. Pearce
@ 2007-04-16 7:59 ` Michael S. Tsirkin
2007-04-16 12:56 ` Alex Riesen
1 sibling, 0 replies; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 7:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Michael S. Tsirkin, Git Mailing List
> Of course I'm one of those "gah, I got more shells than I know what
> I'm doing with!" people. ;-)
Me too :)
--
MST
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 7:11 ` Shawn O. Pearce
2007-04-16 7:59 ` Michael S. Tsirkin
@ 2007-04-16 12:56 ` Alex Riesen
2007-04-16 17:46 ` Junio C Hamano
1 sibling, 1 reply; 70+ messages in thread
From: Alex Riesen @ 2007-04-16 12:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Michael S. Tsirkin, Git Mailing List
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? :)
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] remove shortlog from git-commit output
2007-04-16 6:04 ` Junio C Hamano
2007-04-16 6:26 ` Michael S. Tsirkin
@ 2007-04-16 14:40 ` Michael S. Tsirkin
2007-04-16 15:02 ` Julian Phillips
1 sibling, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
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?
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
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] remove shortlog from git-commit output
2007-04-16 14:40 ` [PATCH] remove shortlog from git-commit output Michael S. Tsirkin
@ 2007-04-16 15:02 ` Julian Phillips
2007-04-16 18:23 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Julian Phillips @ 2007-04-16 15:02 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
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 ...
--
Julian
---
BOFH Excuse #134:
because of network lag due to too many people playing deathmatch
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] display the subject of the commit just made
2007-04-16 12:56 ` Alex Riesen
@ 2007-04-16 17:46 ` Junio C Hamano
0 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2007-04-16 17:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Shawn O. Pearce, Michael S. Tsirkin, Git Mailing List
"Alex Riesen" <raa.lkml@gmail.com> writes:
> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] remove shortlog from git-commit output
2007-04-16 15:02 ` Julian Phillips
@ 2007-04-16 18:23 ` Michael S. Tsirkin
2007-04-16 20:21 ` Julian Phillips
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-16 18:23 UTC (permalink / raw)
To: Julian Phillips; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] remove shortlog from git-commit output
2007-04-16 18:23 ` Michael S. Tsirkin
@ 2007-04-16 20:21 ` Julian Phillips
2007-04-17 6:02 ` Michael S. Tsirkin
0 siblings, 1 reply; 70+ messages in thread
From: Julian Phillips @ 2007-04-16 20:21 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
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.
--
Julian
---
Uh-oh!! I forgot to submit to COMPULSORY URINALYSIS!
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] remove shortlog from git-commit output
2007-04-16 20:21 ` Julian Phillips
@ 2007-04-17 6:02 ` Michael S. Tsirkin
2007-04-17 7:27 ` Julian Phillips
0 siblings, 1 reply; 70+ messages in thread
From: Michael S. Tsirkin @ 2007-04-17 6:02 UTC (permalink / raw)
To: Julian Phillips; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] remove shortlog from git-commit output
2007-04-17 6:02 ` Michael S. Tsirkin
@ 2007-04-17 7:27 ` Julian Phillips
0 siblings, 0 replies; 70+ messages in thread
From: Julian Phillips @ 2007-04-17 7:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
On Tue, 17 Apr 2007, Michael S. Tsirkin wrote:
>> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~2007-04-17 7:28 UTC | newest]
Thread overview: 70+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-21 12:06 [PATCH] have merge put FETCH_HEAD data in commit message Michael S. Tsirkin
2007-03-21 15:37 ` Junio C Hamano
2007-03-22 5:02 ` Michael S. Tsirkin
2007-03-22 5:09 ` Junio C Hamano
2007-03-22 6:28 ` Michael S. Tsirkin
2007-03-22 7:15 ` Junio C Hamano
2007-03-22 7:41 ` Michael S. Tsirkin
2007-03-22 8:21 ` Junio C Hamano
2007-03-22 8:37 ` Michael S. Tsirkin
2007-03-22 10:31 ` Junio C Hamano
2007-03-22 10:40 ` Michael S. Tsirkin
2007-03-24 10:21 ` Junio C Hamano
2007-04-04 6:02 ` Michael S. Tsirkin
2007-04-04 6:09 ` Junio C Hamano
2007-04-04 6:18 ` Michael S. Tsirkin
2007-04-04 6:19 ` Shawn O. Pearce
2007-04-04 6:25 ` Junio C Hamano
2007-04-04 6:35 ` Shawn O. Pearce
2007-04-04 6:24 ` Junio C Hamano
2007-04-04 7:01 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
2007-04-04 7:22 ` Junio C Hamano
2007-04-15 22:39 ` Michael S. Tsirkin
2007-04-15 23:08 ` Junio C Hamano
2007-04-16 3:53 ` [PATCH] display the subject of the commit just made Michael S. Tsirkin
2007-04-16 5:16 ` Junio C Hamano
2007-04-16 5:40 ` Michael S. Tsirkin
2007-04-16 6:17 ` Junio C Hamano
2007-04-16 5:51 ` Michael S. Tsirkin
2007-04-16 6:01 ` Junio C Hamano
2007-04-16 6:18 ` Michael S. Tsirkin
2007-04-16 6:51 ` Michael S. Tsirkin
2007-04-16 7:00 ` Junio C Hamano
2007-04-16 7:11 ` Shawn O. Pearce
2007-04-16 7:59 ` Michael S. Tsirkin
2007-04-16 12:56 ` Alex Riesen
2007-04-16 17:46 ` Junio C Hamano
2007-04-16 5:34 ` [PATCH] display shortlog after git-commit Michael S. Tsirkin
2007-04-16 6:04 ` Junio C Hamano
2007-04-16 6:26 ` Michael S. Tsirkin
2007-04-16 14:40 ` [PATCH] remove shortlog from git-commit output Michael S. Tsirkin
2007-04-16 15:02 ` Julian Phillips
2007-04-16 18:23 ` Michael S. Tsirkin
2007-04-16 20:21 ` Julian Phillips
2007-04-17 6:02 ` Michael S. Tsirkin
2007-04-17 7:27 ` Julian Phillips
2007-04-04 8:15 ` [PATCH] display shortlog after git-commit Junio C Hamano
2007-04-15 10:33 ` Michael S. Tsirkin
2007-04-15 19:57 ` Junio C Hamano
2007-04-15 20:09 ` Michael S. Tsirkin
2007-04-15 20:26 ` Andy Parkins
2007-04-15 20:34 ` Michael S. Tsirkin
2007-04-04 6:24 ` [PATCH] wt-status: show author info if status.showauthor is set Jeff King
2007-04-04 6:32 ` Junio C Hamano
2007-04-04 6:49 ` Michael S. Tsirkin
2007-04-04 6:52 ` Junio C Hamano
2007-04-04 6:55 ` Shawn O. Pearce
2007-04-04 13:28 ` Jakub Narebski
2007-03-23 13:57 ` [PATCH] have merge put FETCH_HEAD data in commit message Jakub Narebski
2007-03-23 13:59 ` J. Bruce Fields
2007-03-23 14:23 ` Jakub Narebski
2007-03-23 15:33 ` J. Bruce Fields
2007-03-24 0:03 ` Jakub Narebski
2007-03-22 9:07 ` [PATCH] Put FETCH_HEAD data in merge " Michael S. Tsirkin
2007-03-22 10:01 ` Junio C Hamano
2007-03-22 8:33 ` [PATCH] have merge put FETCH_HEAD data in " Jeff King
2007-03-22 8:51 ` Junio C Hamano
2007-03-22 9:09 ` Jeff King
2007-03-22 9:10 ` Andy Parkins
2007-03-21 17:29 ` [PATCHv2] put FETCH_HEAD data in merge " Michael S. Tsirkin
2007-03-21 18:09 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).