From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
The following patch series adds the ability to configure aliases for
user-defined formats. The first two patches define new placeholders and
modify the output of existing placeholders to allow aliases to be more
consistent with the way builtin formats are handled. The final patch
adds support for the aliases themselves.
There were a couple of places where I wasn't entirely sure about which
color setting I should be following, but I've tried to be consistent
throughout. It may be that I could have simply followed diffopt's color
option in all cases, in which case various modifications to show_log()
were entirely unnecessary. I'll await judgement at the hands of one who
groks those sections more than I do, but I think what I've done feels
correct.
My original goal was to make it possible to define all of the builtin
formats as builtin aliases to format strings, but complications
regarding how --parents and --decorate would be handled require further
thought and discussion. For example, we could simply make
"--format=%H --decorate" synonymous with "--format=%H%d", but I'm not
sure if that feels clean enough.
For now, I think this is at a point where its good-enough to submit, if
only as a starting point for some discussion as to where to head next.
This is the second version of the patch. Following feedback from Jeff
King [off-list ref], I realized that the modification to the arguments
of show_log() were unnecessary, as they only made a difference within
show-branch.c, which does not accept a --format option in any case.
Will Palmer (3):
pretty: add conditional %C?colorname placeholders
pretty: make %H/%h dependent on --abbrev[-commit]
pretty: add aliases for pretty formats
Documentation/config.txt | 8 ++
Documentation/pretty-formats.txt | 1 +
builtin/log.c | 2 +-
builtin/rev-list.c | 2 +
builtin/shortlog.c | 7 +-
commit.h | 2 +
log-tree.c | 3 +
pretty.c | 248 ++++++++++++++++++++++++++++++--------
shortlog.h | 2 +-
t/t4205-log-pretty-formats.sh | 87 +++++++++++++
10 files changed, 307 insertions(+), 55 deletions(-)
create mode 100755 t/t4205-log-pretty-formats.sh
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
Many commands are able to colorize, or not, depending on a user's
configuration and whether output is being sent to a terminal. However,
if a user explicitly specifies a --pretty format, color will always be
output, regardless of the destination. This would generally be okay, in
a "do what I tell you, whether or not I should tell you to" sense, but
the assumption fell apart when an alias was defined which may be run in
various contexts: there was no way to specify "use this color, but only
if you normally would display color at all"
Here we add the %C?colorname placeholders which act just as the
%Ccolorname placeholders, with the exception that the pretty_context is
checked to see if color should be used according to configuration
Signed-off-by: Will Palmer <redacted>
---
Documentation/pretty-formats.txt | 1 +
builtin/log.c | 2 +-
builtin/rev-list.c | 1 +
builtin/shortlog.c | 5 ++-
commit.h | 1 +
log-tree.c | 1 +
pretty.c | 49 ++++++++++++++++++++++++-------------
shortlog.h | 2 +-
t/t4205-log-pretty-formats.sh | 44 ++++++++++++++++++++++++++++++++++
9 files changed, 85 insertions(+), 21 deletions(-)
create mode 100755 t/t4205-log-pretty-formats.sh
@@ -132,6 +132,7 @@ The placeholders are: - '%Cblue': switch color to blue - '%Creset': reset color - '%C(...)': color specification, as described in color.branch.* config option+- '%C?...: switch to specified color, if relevant color.* config option specifies that color is ok - '%m': left, right or boundary mark - '%n': newline - '%%': a raw '%'
@@ -0,0 +1,44 @@+#!/bin/sh+#+# Released into Public Domain by Will Palmer 2010+#++test_description='Test pretty formats'+../test-lib.sh++test_expect_success"set up basic repos"">foo && git add foo && git commit -m initial"++forflaginfalsetruealways;do+forcolorinredgreenbluereset;do++make_expected="git config --get-color no.such.slot $color >expected"+test_expect_success"%C$color with color.ui $flag"\+"$make_expected &&+gitconfigcolor.ui$flag&&+gitlog-1--pretty=format:'%C$color'>actual&&+cmpexpectedactual"+++test_expect_success"%C($color) with color.ui $flag"\+"$make_expected &&+gitconfigcolor.ui$flag&&+gitlog-1--pretty=format:'%C($color)'>actual&&+cmpexpectedactual"++[!"$flag"="always"]&&make_expected=">expected"+test_expect_success"%C?$color with color.ui $flag"\+"$make_expected &&+gitconfigcolor.ui$flag&&+gitlog-1--pretty=format:'%C?$color'>actual&&+cmpexpectedactual"++test_expect_success"%C?($color) with color.ui $flag"\+"$make_expected &&+gitconfigcolor.ui$flag&&+gitlog-1--pretty=format:'%C?($color)'>actual&&+cmpexpectedactual"++done+done++test_done
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
Prior to this, the output of %H was always 40 characters long, and the
output of %h always DEFAULT_ABBREV characters long, without regard to
whether --abbrev-commit or --abbrev had been passed.
Here we make "git log --pretty=%H --abbrev-commit" synonymous with
"git log --pretty=%h", and make %h/abbreviated-%H respect the length
specified for --abbrev.
The same is applied to other commit-placeholders %P and %p, and
--abbrev is respected for %t, though %T is not changed.
Signed-off-by: Will Palmer <redacted>
---
builtin/rev-list.c | 1 +
builtin/shortlog.c | 2 ++
commit.h | 1 +
log-tree.c | 2 ++
pretty.c | 30 +++++++++++++++++++-----------
5 files changed, 25 insertions(+), 11 deletions(-)
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
previously the only ways to alias a --pretty format within git were
either to set the format as your default format (via the format.pretty
configuration variable), or by using a regular git alias. This left the
definition of more complicated formats to the realm of "builtin or
nothing", with user-defined formats usually being reserved for quick
one-offs.
Here we allow user-defined formats to enjoy more or less the same
benefits of builtins. By defining format.pretty.myalias, "myalias" can
be used in place of whatever would normally come after --pretty=. This
can be a format:, tformat:, raw (ie, defaulting to tformat), or the name
of another builtin or user-defined pretty format.
Signed-off-by: Will Palmer <redacted>
---
Documentation/config.txt | 8 ++
pretty.c | 169 +++++++++++++++++++++++++++++++++++------
t/t4205-log-pretty-formats.sh | 53 ++++++++++++-
3 files changed, 202 insertions(+), 28 deletions(-)
@@ -894,6 +894,14 @@ format.pretty:: See linkgit:git-log[1], linkgit:git-show[1], linkgit:git-whatchanged[1].+format.pretty.<name>::+ Alias for a --pretty= format string, as specified in+ linkgit:git-log[1]. Any aliases defined here can be used just+ as the builtin pretty formats could. For example, defining+ "format.pretty.hash = format:%H" would cause the invocation+ "git log --pretty=hash" to be equivalent to running+ "git log --pretty=format:%H".+ format.thread:: The default threading style for 'git format-patch'. Can be a boolean value, or `shallow` or `deep`. `shallow` threading
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Hi Will,
Will Palmer wrote:
Here we add the %C?colorname placeholders which act just as the
%Ccolorname placeholders, with the exception that the pretty_context is
checked to see if color should be used according to configuration
Thanks for tackling this.
I have thought a little about a related problem: some commands have
configuration for the colors they use, like:
color.grep.<slot>
Use customized color for grep colorization. <slot> specifies which
part of the line to use the specified color, and is one of
context
non-matching text in context lines (when using -A, -B, or -C)
filename
filename prefix (when not using -h)
This is nice because in certain situations (e.g. different background
colors), the default colors might not be suitable. As an example of
this, the ‘commit ’ line of ‘git log’ output uses color.diff.commit.
So it would be nice to be able to use %C(diff.commit) and
automatically use the right color, if color is enabled.
Why not make %C always check? I can understand that it would be
annoying when first trying to use %C. On the other hand, it would be
more convenient for writing format.pretty configuration that should be
shared with old git, and I assume anyone using %C for the first time
would be looking at the manual, which could warn her.
Cheers,
Jonathan
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Will Palmer wrote:
Here we make "git log --pretty=%H --abbrev-commit" synonymous with
"git log --pretty=%h", and make %h/abbreviated-%H respect the length
specified for --abbrev.
The same is applied to other commit-placeholders %P and %p, and
--abbrev is respected for %t, though %T is not changed.
Signed-off-by: Will Palmer <redacted>
---
builtin/rev-list.c | 1 +
builtin/shortlog.c | 2 ++
commit.h | 1 +
log-tree.c | 2 ++
pretty.c | 30 +++++++++++++++++++-----------
5 files changed, 25 insertions(+), 11 deletions(-)
I agree that this is the right to do, since this is how the built-in
formats work (the ‘commit ...’ line follows the semantics of your %H,
and ‘Merge: ...’ line your %p, for example).
Documentation and tests?
nitpick: the new indentation makes these look like parameters to
strbuf_addstr.
Here’s an alternative implementation of the more controversial half of
your patch, for your amusement. The big downside is that it requires
one to specify --abbrev-commit before the --format option.
Thanks for the pleasant read.
Jonathan
From: Jeff King <hidden> Date: 2016-06-15 22:48:42
On Sun, Apr 25, 2010 at 09:13:47PM -0500, Jonathan Nieder wrote:
This is nice because in certain situations (e.g. different background
colors), the default colors might not be suitable. As an example of
this, the ‘commit ’ line of ‘git log’ output uses color.diff.commit.
So it would be nice to be able to use %C(diff.commit) and
automatically use the right color, if color is enabled.
FWIW, I like this idea very much. And it would be a bit more natural for
%C(diff.commit) to respect diff.color, whereas we could perhaps keep
%Cred as "always on" for backwards compatibility.
However:
Why not make %C always check? I can understand that it would be
annoying when first trying to use %C. On the other hand, it would be
I am a little nervous that we would be breaking scripts that pipe the
colorized output for later display to the user. Right now doing
something like[1]:
log=`git log --format=%Cred%h`
test "x$log" != x && echo "foo: $log"
colorizes, but we would be breaking it. And for new values like
%C(diff.commit), we are not breaking anything (because it is a new
syntax), but a script like the one above may want to convert, and there
is no way to say "respect the color _config_, but don't respect
isatty(1)". Saying "--color" doesn't work, because it overrides the
color config. We can cheat a little with GIT_PAGER_IN_USE, but that will
have funny interactions with pager.color.
[1] Yes, I know this snippet is contrived, but it seems within the realm
of possibility. git-add--interactive reads the diff output in both
regular and color forms, though it takes some care to look at the user's
config and decide whether to show the color.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:48:42
On Sun, Apr 25, 2010 at 10:11:37PM -0500, Jonathan Nieder wrote:
Here’s an alternative implementation of the more controversial half of
your patch, for your amusement. The big downside is that it requires
one to specify --abbrev-commit before the --format option.
That is not insurmountable, as we could just check after the parsing
stage. But there is a worse problem:
+static void abbreviate_commit_hashes(char *fmt)
+{
+ char *p;
+ for (p = fmt; p != NULL; p = strchr(p + 1, '%')) {
+ p++;
+ switch (*p) {
+ case 'H':
+ *p = 'h';
+ break;
+ case 'P':
+ *p = 'p';
+ break;
+ case 'T':
+ default:
+ break;
+ }
+ }
+}
You parse '%%H' incorrectly. I would really rather not see ad-hoc
parsers for the format like this, but rather use or extend strbuf_expand
as appropriate. That would make things less painful if and when we
decide to tweak the syntax.
I think a lot of this might be more pleasant if we had some extensible
and backwards compatible syntax like %(placeholder, arg, ...) and could
do "%(H, abbrev=always)" or "%(H, abbrev=config)". Yeah, it's long, but
it is readable and explicit.
-Peff
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Jeff King wrote:
On Sun, Apr 25, 2010 at 10:11:37PM -0500, Jonathan Nieder wrote:
quoted
Here’s an alternative implementation of the more controversial half of
your patch, for your amusement. The big downside is that it requires
one to specify --abbrev-commit before the --format option.
That is not insurmountable, as we could just check after the parsing
stage. But there is a worse problem:
quoted
+static void abbreviate_commit_hashes(char *fmt)
+{
+ char *p;
+ for (p = fmt; p != NULL; p = strchr(p + 1, '%')) {
+ p++;
+ switch (*p) {
+ case 'H':
+ *p = 'h';
+ break;
+ case 'P':
+ *p = 'p';
+ break;
+ case 'T':
+ default:
+ break;
+ }
+ }
+}
You parse '%%H' incorrectly.
I’m pretty sure I don’t.
I would really rather not see ad-hoc
parsers for the format like this, but rather use or extend strbuf_expand
as appropriate. That would make things less painful if and when we
decide to tweak the syntax.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Jonathan Nieder wrote:
Jeff King wrote:
quoted
On Sun, Apr 25, 2010 at 10:11:37PM -0500, Jonathan Nieder wrote:
quoted
quoted
+static void abbreviate_commit_hashes(char *fmt)
+{
+ char *p;
+ for (p = fmt; p != NULL; p = strchr(p + 1, '%')) {
+ p++;
+ switch (*p) {
+ case 'H':
+ *p = 'h';
+ break;
+ case 'P':
+ *p = 'p';
+ break;
+ case 'T':
+ default:
+ break;
+ }
+ }
+}
You parse '%%H' incorrectly.
I’m pretty sure I don’t.
Aggh, I see it now. The first line should be
for (p = strchr(fmt, '%'); ...
as I would have noticed with even a little testing.
Sorry for the nonsense.
Jonathan
From: Jeff King <hidden> Date: 2016-06-15 22:48:42
On Sun, Apr 25, 2010 at 10:41:35PM -0500, Jonathan Nieder wrote:
Jonathan Nieder wrote:
quoted
Jeff King wrote:
quoted
On Sun, Apr 25, 2010 at 10:11:37PM -0500, Jonathan Nieder wrote:
quoted
quoted
quoted
+static void abbreviate_commit_hashes(char *fmt)
+{
+ char *p;
+ for (p = fmt; p != NULL; p = strchr(p + 1, '%')) {
+ p++;
+ switch (*p) {
+ case 'H':
+ *p = 'h';
+ break;
+ case 'P':
+ *p = 'p';
+ break;
+ case 'T':
+ default:
+ break;
+ }
+ }
+}
You parse '%%H' incorrectly.
I’m pretty sure I don’t.
Aggh, I see it now. The first line should be
for (p = strchr(fmt, '%'); ...
as I would have noticed with even a little testing.
Actually, we are both failing. You _do_ parse %%H right, but you don't
parse "WHO" correctly. So yours is a different bug than what I thought.
:)
-Peff
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Jeff King wrote:
I am a little nervous that we would be breaking scripts that pipe the
colorized output for later display to the user. Right now doing
something like[1]:
log=`git log --format=%Cred%h`
test "x$log" != x && echo "foo: $log"
colorizes, but we would be breaking it. And for new values like
%C(diff.commit), we are not breaking anything (because it is a new
syntax), but a script like the one above may want to convert, and there
is no way to say "respect the color _config_, but don't respect
isatty(1)". Saying "--color" doesn't work, because it overrides the
color config. We can cheat a little with GIT_PAGER_IN_USE, but that will
have funny interactions with pager.color.
Very interesting. I think the natural solution (for new colors) would
be a --color=config option, which would require parsing options before
checking configuration.
Does this sound sane?
Jonathan
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Will Palmer wrote:
format.pretty.<name>::
Alias for a --pretty= format string, as specified in
linkgit:git-log[1]. Any aliases defined here can be used just
as the builtin pretty formats could. For example, defining
"format.pretty.hash = format:%H" would cause the invocation
"git log --pretty=hash" to be equivalent to running
"git log --pretty=format:%H".
Ah, so I could use
[format "pretty"]
wrapped = "format:\
%C(yellow)commit %H%n\
Merge: %p%n\
Author: %aN <%aE>%n\
Date: %ad%n%n%w(80,4,4)%s%n\
%+b"
and then by default I get the standard medium, but with --format=wrapped,
I get my imitation of it. Sounds very useful, thanks.
Why not build it in place? Not for performance reasons (that could go
either way); it is just that that would seem simpler to me.
+ }
+ return 0;
+}
Regarding the next piece: I suspect the review would be easier if
it had been more than one patch. Maybe three patches:
1 restructure get_commit_format to read from a (dynamic) list of
supported formats that is not its responsibility
2 infrastructure for format aliases (this is not needed for
--format=datelist where datelist = "tformat:%h %cd")
3 new configuration for user-defined formats and format aliases
Maybe 3 could come before 2, since it seems like complicated.
The new call graph looks like this:
setup_revisions() ->
handle_revision_opt() ->
get_commit_format() ->
find_commit_format() ->
setup_commit_formats() ->
git_config() ->
git_pretty_formats_config()
This means we have to have searched for a repository before parsing
these arguments; this constraint already exists for parsing the actual
revision arguments (maybe some day we will defer handling those
arguments for some reason).
I would have put the setup_commit_formats() call in setup_revisions()
to make this more obvious, but I suppose this way you save time if no
--format option is used.
Example:
[format "pretty"]
foo = medium
xyzzy = one
one = foo
two = foo
frotz = two
At the end of this loop, attempted_aliases contains:
one
foo
two
Every alias which is itself referred to by an alias is listed.
Why go to the trouble to build attempted_aliases when it is never used?
I suspect I’ve completely misunderstood, so I’m stopping here. Maybe
someone else can clear it up or take over.
Jonathan
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
I agree that this is the right to do, since this is how the built-in
formats work (the ‘commit ...’ line follows the semantics of your %H,
and ‘Merge: ...’ line your %p, for example).
Documentation and tests?
Tests, noted. I'll include some in the next version of the patch.
As for documentation, I'm not entirely sure what to add, as it seemed
like the change
merely implements what I would expect when reading the docs for
git-log. Still, noted.
I'll stick a short note in each of %H, %h, %P, %p, and %t
Shortlog doesn’t print commit hashes, does it?
Shortlog accepts --format, though this doesn't seem to be documented
(if I type "man" and search
for "format"), so perhaps it should be.
There is a
ctx.abbrev = opt->diffopt.abbrev;
later in the same function; how do these interact?
I hadn't caught that. My guess: stupidly doing the same thing twice.
I'll double-check,
and take out one of them if that's the case.
What all this
has shown me is that there are really too many ways to specify "context when
printing information about a commit". I don't like it, and the lot of
them can probably
be re-factored, perhaps by getting rid of pretty_context and passing
rev_info around
everywhere. I don't know the full implications of that and it seems
outside the scope
of this change.
nitpick: the new indentation makes these look like parameters to
strbuf_addstr.
Noted. I'll restore the extra indent, which I had assumed was a typo.
quoted hunk
Here’s an alternative implementation of the more controversial half of
your patch, for your amusement. The big downside is that it requires
one to specify --abbrev-commit before the --format option.
Thanks for the pleasant read.
Jonathan
I had been thinking that this wouldn't be safe, but then that was my
being overly-cautious:
it's just been xstrdup()ed, so what we're parsing is ours, no real
reason not to do it.
I think the "must be specified after --abbrev-commit" is a rather
large nail, though. If you work
out the bugs mentioned by Jeff King, and it works, I'll stick it in
there, as I don't like
falling through case statements any more than the next guy. (well,
maybe a little more than
the next guy).
Thanks for the review!
-- Will Palmer
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
I don't have time right now to reply line-by-line to this, so this is
just an ACK that it was
received, and I'll reply later today.
On Mon, Apr 26, 2010 at 8:25 AM, Jonathan Nieder [off-list ref] wrote:
Will Palmer wrote:
quoted
format.pretty.<name>::
Alias for a --pretty= format string, as specified in
linkgit:git-log[1]. Any aliases defined here can be used just
as the builtin pretty formats could. For example, defining
"format.pretty.hash = format:%H" would cause the invocation
"git log --pretty=hash" to be equivalent to running
"git log --pretty=format:%H".
Ah, so I could use
[format "pretty"]
wrapped = "format:\
%C(yellow)commit %H%n\
Merge: %p%n\
Author: %aN <%aE>%n\
Date: %ad%n%n%w(80,4,4)%s%n\
%+b"
and then by default I get the standard medium, but with --format=wrapped,
I get my imitation of it. Sounds very useful, thanks.
Why not build it in place? Not for performance reasons (that could go
either way); it is just that that would seem simpler to me.
quoted
+ }
+ return 0;
+}
Regarding the next piece: I suspect the review would be easier if
it had been more than one patch. Maybe three patches:
1 restructure get_commit_format to read from a (dynamic) list of
supported formats that is not its responsibility
2 infrastructure for format aliases (this is not needed for
--format=datelist where datelist = "tformat:%h %cd")
3 new configuration for user-defined formats and format aliases
Maybe 3 could come before 2, since it seems like complicated.
The new call graph looks like this:
setup_revisions() ->
handle_revision_opt() ->
get_commit_format() ->
find_commit_format() ->
setup_commit_formats() ->
git_config() ->
git_pretty_formats_config()
This means we have to have searched for a repository before parsing
these arguments; this constraint already exists for parsing the actual
revision arguments (maybe some day we will defer handling those
arguments for some reason).
I would have put the setup_commit_formats() call in setup_revisions()
to make this more obvious, but I suppose this way you save time if no
--format option is used.
Example:
[format "pretty"]
foo = medium
xyzzy = one
one = foo
two = foo
frotz = two
At the end of this loop, attempted_aliases contains:
one
foo
two
Every alias which is itself referred to by an alias is listed.
Why go to the trouble to build attempted_aliases when it is never used?
I suspect I’ve completely misunderstood, so I’m stopping here. Maybe
someone else can clear it up or take over.
Jonathan
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Follow the current prevailing style. This also has the benefit of
capturing any stray output and noticing if any of the setup commands
start failing.
Signed-off-by: Jonathan Nieder <redacted>
---
t/t4201-shortlog.sh | 68 +++++++++++++++++++++++++++++---------------------
1 files changed, 39 insertions(+), 29 deletions(-)
@@ -8,30 +8,38 @@ test_description='git shortlog ../test-lib.sh-echo1>a1-gitadda1-tree=$(gitwrite-tree)-commit=$((echo"Test";echo)|gitcommit-tree$tree)-gitupdate-refHEAD$commit--echo2>a1-gitcommit--quiet-m"This is a very, very long first line for the commit message to see if it is wrapped correctly"a1--# test if the wrapping is still valid when replacing all i's by treble clefs.-echo3>a1-gitcommit--quiet-m"$(echo"This is a very, very long first line for the commit message to see if it is wrapped correctly"|sed"s/i/1234/g"|tr1234'\360\235\204\236')"a1--# now fsck up the utf8-gitconfigi18n.commitencodingnon-utf-8-echo4>a1-gitcommit--quiet-m"$(echo"This is a very, very long first line for the commit message to see if it is wrapped correctly"|sed"s/i/1234/g"|tr1234'\370\235\204\236')"a1--echo5>a1-gitcommit--quiet-m"a 12 34 56 78"a1--gitshortlog-wHEAD>out+test_expect_success'setup''+echo1>a1&&+gitadda1&&+tree=$(gitwrite-tree)&&+commit=$(printf"%s\n""Test"""|gitcommit-tree"$tree")&&+gitupdate-refHEAD"$commit"&&++echo2>a1&&+gitcommit--quiet-m"This is a very, very long first line for the commit message to see if it is wrapped correctly"a1&&++# test if the wrapping is still valid+# when replacing all is by treble clefs.+echo3>a1&&+gitcommit--quiet-m"$(+echo"This is a very, very long first line for the commit message to see if it is wrapped correctly"|+sed"s/i/1234/g"|+tr1234"\360\235\204\236")" a1 &&++# now fsck up the utf8+gitconfigi18n.commitencodingnon-utf-8&&+echo4>a1&&+gitcommit--quiet-m"$(+echo"This is a very, very long first line for the commit message to see if it is wrapped correctly"|+sed"s/i/1234/g"|+tr1234"\370\235\204\236")" a1 &&++echo5>a1&&+gitcommit--quiet-m"a 12 34 56 78"a1+'-cat>expect<<EOF+test_expect_success'shortlog wrapping''+cat>expect<<\EOF&& AUThor(5):TestThisisavery,verylongfirstlineforthecommitmessagetoseeif
@@ -44,13 +52,15 @@ A U Thor (5):5678 EOF+gitshortlog-wHEAD>out&&+test_cmpexpectout+'-test_expect_success'shortlog wrapping''test_cmp expect out'--gitlogHEAD>log-GIT_DIR=non-existinggitshortlog-w<log>out--test_expect_success'shortlog from non-git directory''test_cmp expect out'+test_expect_success'shortlog from non-git directory''+gitlogHEAD>log&&+GIT_DIR=non-existinggitshortlog-w<log>out&&+test_cmpexpectout+' iconvfromutf8toiso88591(){printf"%s""$*"|iconv-fUTF-8-tISO8859-1
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Signed-off-by: Jonathan Nieder <redacted>
---
This could be squashed with patch 1, if you like.
t/t4201-shortlog.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Do not document the --pretty synonym, since it takes too long to
explain the name to people.
Signed-off-by: Jonathan Nieder <redacted>
---
Documentation/git-shortlog.txt | 8 ++++++
t/t4201-shortlog.sh | 53 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 60 insertions(+), 1 deletions(-)
@@ -39,6 +39,14 @@ OPTIONS --email:: Show the email address of each author.+--format[='<format>']::+ Instead of the commit subject, use some other information to+ describe each commit. '<format>' can be any string accepted+ by the `--format` option of 'git log', such as '* [%h] %s'.+ (See the "PRETTY FORMATS" section of linkgit:git-log[1].)++ Each pretty-printed commit will be rewrapped before it is shown.+ -w[<width>[,<indent1>[,<indent2>]]]:: Linewrap the output by wrapping each line at `width`. The first line of each entry is indented by `indent1` spaces, and the second
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
From: Will Palmer <redacted>
Prior to this, the output of git log -1 --format=%h was always 7
characters long, without regard to whether --abbrev had been passed.
Signed-off-by: Will Palmer <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
That’s the end of the series. Thanks for reading.
builtin/shortlog.c | 3 ++-
pretty.c | 7 ++++---
shortlog.h | 1 +
t/t4201-shortlog.sh | 2 +-
t/t6006-rev-list-format.sh | 19 +++++++++++++++++++
5 files changed, 27 insertions(+), 5 deletions(-)
@@ -290,6 +290,7 @@ parse_done:}log.user_format=rev.commit_format==CMIT_FMT_USERFORMAT;+log.abbrev=rev.abbrev;/* assume HEAD if from a tty */if(!nongit&&!rev.pending.nr&&isatty(0))
@@ -191,6 +191,19 @@ test_expect_success 'add LF before non-empty (2)' 'grep"^$"actual'+test_expect_success'--abbrev''+echoSHORTSHORTSHORT>expect2&&+echoLONGLONGLONG>expect3&&+gitlog-1--format="%h %h %h"HEAD>actual1&&+gitlog-1--abbrev=5--format="%h %h %h"HEAD>actual2&&+gitlog-1--abbrev=5--format="%H %H %H"HEAD>actual3&&+sed-e"s/$_x40/LONG/g"-e"s/$_x05/SHORT/g"<actual2>fuzzy2&&+sed-e"s/$_x40/LONG/g"-e"s/$_x05/SHORT/g"<actual3>fuzzy3&&+test_cmpexpect2fuzzy2&&+test_cmpexpect3fuzzy3&&+!test_cmpactual1actual2+'+ test_expect_success'"%h %gD: %gs" is same as git-reflog''gitreflog>expect&&gitlog-g--format="%h %gD: %gs">actual&&
@@ -203,6 +216,12 @@ test_expect_success '"%h %gD: %gs" is same as git-reflog (with date)' 'test_cmpexpectactual'+test_expect_success'"%h %gD: %gs" is same as git-reflog (with --abbrev)''+gitreflog--abbrev=13--date=raw>expect&&+gitlog-g--abbrev=13--format="%h %gD: %gs"--date=raw>actual&&+test_cmpexpectactual+'+ test_expect_success'%gd shortens ref name''echo"master@{0}">expect.gd-short&&gitlog-g-1--format=%gdrefs/heads/master>actual.gd-short&&
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
On Mon, Apr 26, 2010 at 10:53 AM, Jonathan Nieder [off-list ref] wrote:
Will Palmer wrote:
quoted
Jonathan Nieder wrote:
quoted
quoted
Shortlog doesn’t print commit hashes, does it?
Shortlog accepts --format, though this doesn't seem to be documented
(if I type "man" and search
for "format"), so perhaps it should be.
Oh, neat! Maybe this would save you the trouble.
Jonathan Nieder (3):
t4201 (shortlog): guard setup with test_expect_success
t4201 (shortlog): Test output format with multiple authors
shortlog: Document and test --format option
Thanks!
I wasn't sure if you intended this to be submitted as a separate
series or added on top of my series,
as my mail client grouped them together (I really need to stop using
gmail for the mailing list...). If the latter,
I'd appreciate it being sent in as a separate series, as I'd consider
the shortlog documentation/testing to be a
separate topic. (Though I suppose I should add tests for shortlog to
the tests I wrote)
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Will Palmer wrote:
I wasn't sure if you intended this to be submitted as a separate
series or added on top of my series,
as my mail client grouped them together (I really need to stop using
gmail for the mailing list...).
I sent it as a reply, but the patches are against master. The last of
the four patches is from your series with a few small changes and its
in-message From: line is set accordingly. Sorry for the confusion.
Jonathan
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
Jonathan Nieder wrote:
I sent it as a reply, but the patches are against master. The last of
the four patches is from your series with a few small changes and its
in-message From: line is set accordingly. Sorry for the confusion.
Jonathan
I think the documentation / test changes are needed, but my
own patch will probably go through several more revisions
before it is ready to be included, which is why I suggested
submitting your series separately.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:42
Will Palmer wrote:
I think the documentation / test changes are needed, but my
own patch will probably go through several more revisions
before it is ready to be included, which is why I suggested
submitting your series separately.
Oh, I only took the uncontroversial part. ;-)
Jonathan
From: Jeff King <hidden> Date: 2016-06-15 22:48:42
On Sun, Apr 25, 2010 at 11:14:12PM -0500, Jonathan Nieder wrote:
quoted
%C(diff.commit), we are not breaking anything (because it is a new
syntax), but a script like the one above may want to convert, and there
is no way to say "respect the color _config_, but don't respect
isatty(1)". Saying "--color" doesn't work, because it overrides the
color config. We can cheat a little with GIT_PAGER_IN_USE, but that will
have funny interactions with pager.color.
Very interesting. I think the natural solution (for new colors) would
be a --color=config option, which would require parsing options before
checking configuration.
Does this sound sane?
From: Will Palmer <hidden> Date: 2016-06-15 22:48:42
On Mon, 2010-04-26 at 02:25 -0500, Jonathan Nieder wrote:
... a lot ...
Now that I've had a chance to fully read through this, I see that I
can't actually just go through line-by-line and respond to it off the
top of my head. I've made a note of everything, and anything which is
not directly addressed in the next version, should at least be addressed
in the cover-letter.
Thank you very much for taking time to review this
--
-- Will