1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-31 22:37:54 +01:00
Commit graph

30 commits

Author SHA1 Message Date
Junio C Hamano
b8e533f12a Merge branch 'hj/pretty-naked-decoration'
The pretty-format specifier "%d", which expanded to " (tagname)"
for a tagged commit, gained a cousin "%D" that just gives the
"tagname" without frills.

* hj/pretty-naked-decoration:
  pretty: add %D format specifier
2014-09-29 12:36:09 -07:00
Junio C Hamano
ceeacc501b Merge branch 'bb/date-iso-strict'
"log --date=iso" uses a slight variant of ISO 8601 format that is
made more human readable.  A new "--date=iso-strict" option gives
datetime output that is more strictly conformant.

* bb/date-iso-strict:
  pretty: provide a strict ISO 8601 date format
2014-09-19 11:38:32 -07:00
Harry Jeffery
9271095cc5 pretty: add %D format specifier
Add a new format specifier, '%D' that is identical in behaviour to '%d',
except that it does not include the ' (' prefix or ')' suffix provided
by '%d'.

Signed-off-by: Harry Jeffery <harry@exec64.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-18 15:15:21 -07:00
Junio C Hamano
1764e8124e Merge branch 'nd/strbuf-utf8-replace'
* nd/strbuf-utf8-replace:
  utf8.c: fix strbuf_utf8_replace() consuming data beyond input string
2014-09-09 12:54:02 -07:00
Beat Bolli
466fb6742d pretty: provide a strict ISO 8601 date format
Git's "ISO" date format does not really conform to the ISO 8601
standard due to small differences, and it cannot be parsed by ISO
8601-only parsers, e.g. those of XML toolchains.

The output from "--date=iso" deviates from ISO 8601 in these ways:

  - a space instead of the `T` date/time delimiter
  - a space between time and time zone
  - no colon between hours and minutes of the time zone

Add a strict ISO 8601 date format for displaying committer and
author dates.  Use the '%aI' and '%cI' format specifiers and add
'--date=iso-strict' or '--date=iso8601-strict' date format names.

See http://thread.gmane.org/gmane.comp.version-control.git/255879 and
http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585
for discussion.

Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-29 12:37:02 -07:00
Nguyễn Thái Ngọc Duy
430875969a utf8.c: fix strbuf_utf8_replace() consuming data beyond input string
The main loop in strbuf_utf8_replace() could summed up as:

  while ('src' is still valid) {
    1) advance 'src' to copy ANSI escape sequences
    2) advance 'src' to copy/replace visible characters
  }

The problem is after #1, 'src' may have reached the end of the string
(so 'src' points to NUL) and #2 will continue to copy that NUL as if
it's a normal character. Because the output is stored in a strbuf,
this NUL accounted in the 'len' field as well. Check after #1 and
break the loop if necessary.

The test does not look obvious, but the combination of %>>() should
make a call trace like this

  show_log()
  pretty_print_commit()
  format_commit_message()
  strbuf_expand()
  format_commit_item()
  format_and_pad_commit()
  strbuf_utf8_replace()

where %C(auto)%d would insert a color reset escape sequence in the end
of the string given to strbuf_utf8_replace() and show_log() uses
fwrite() to send everything to stdout (including the incorrect NUL
inserted by strbuf_utf8_replace)

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-11 11:52:22 -07:00
Pat Thoyts
e6ce2be2d7 tests: do not pass iso8859-1 encoded parameter
git commit -m with some iso8859-1 encoded stuff is doomed to fail in MinGW,
because Windows don't let you pass encoded bytes to a process (CreateProcessW
always takes a UTF-16LE encoded string).

It is safe to pass the iso8859-1 message using a file or a pipe.

Thanks-to: Karsten Blees <blees@dcon.de>
Author: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-15 11:19:11 -07:00
Alexey Shumkin
7d509878b8 pretty.c: format string with truncate respects logOutputEncoding
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.

In 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19)
'format_commit_item' function assumes commit message to be in UTF-8.
And that was so until ecaee80 (pretty: --format output should honor
logOutputEncoding, 2013-06-26) where conversion to logOutputEncoding was
added before calling 'format_commit_message'.

Correct this by converting a commit message to UTF-8 first (as it
assumed in 7e77df3 (pretty: two phase conversion for non utf-8 commits,
2013-04-19)). Only after that convert a commit message to an actual
logOutputEncoding.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21 11:13:30 -07:00
Alexey Shumkin
d928d81051 t4205, t6006: add tests that fail with i18n.logOutputEncoding set
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.

There were no breakages as far as were no tests for the case
when both a commit message and logOutputEncoding are not UTF-8.

Add failing tests for that which will be fixed in the next patch.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21 11:11:50 -07:00
Alexey Shumkin
c82134a9f3 t4205 (log-pretty-format): use tformat rather than format
Use `tformat` to avoid using of `echo` to complete end of line.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21 11:10:10 -07:00
Alexey Shumkin
ee3efaf66c t4041, t4205, t6006, t7102: don't hardcode tested encoding value
The tested encoding is always available in a variable. Use it instead of
hardcoding. Also, to be in line with other tests use ISO8859-1
(uppercase) rather then iso8859-1.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21 11:10:06 -07:00
Alexey Shumkin
496a69802b t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

That was introduced in a742f2a (t4205 (log-pretty-formats): don't
hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was
not followed in 5e1361c (log: properly handle decorations with chained
tags, 2013-12-17)

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19 11:24:46 -07:00
brian m. carlson
5e1361ccdb log: properly handle decorations with chained tags
git log did not correctly handle decorations when a tag object referenced
another tag object that was no longer a ref, such as when the second tag was
deleted.  The commit would not be decorated correctly because parse_object had
not been called on the second tag and therefore its tagged field had not been
filled in, resulting in none of the tags being associated with the relevant
commit.

Call parse_object to fill in this field if it is absent so that the chain of
tags can be dereferenced and the commit can be properly decorated.  Include
tests as well to prevent future regressions.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-20 14:37:03 -08:00
Alexey Shumkin
37eb772ef3 t4205 (log-pretty-formats): avoid using sed
For testing truncated log messages 'commit_msg' function uses `sed` to
cut a message. On various platforms `sed` behaves differently and
results of its work depend on locales installed. So, avoid using `sed`.
Use predefined expected outputs instead of calculated ones.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05 11:54:53 -07:00
Alexey Shumkin
17cc2ef1c5 t4205, t6006, t7102: make functions better readable
Function 'test_format' has become harder to read after its change in
de6029a2 (pretty: Add failing tests: --format output should honor
logOutputEncoding, 2013-06-26). Simplify it by moving its "should we
expect it to fail?" parameter to the end.

Note, current code does not use this last parameter as far as there
are no tests expected to fail. We can keep that for future use.

Also, reformat comments.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Improved-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05 11:40:18 -07:00
Alexey Shumkin
f3445f781f t4205 (log-pretty-formats): revert back single quotes
In previuos commit de6029a (pretty: Add failing tests: --format output
should honor logOutputEncoding, 2013-06-26) single quotes were replaced
with double quotes to make "$(commit_msg)" expression in heredoc to
work. The same effect can be achieved by using "EOF" as a heredoc
delimiter instead of "\EOF".

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Suggested-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05 11:35:39 -07:00
Alexey Shumkin
14332bccc1 t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1
Both "iso8859-1" and "iso-8859-1" are understood as latin-1 by
modern platforms, but the latter is not understood by older
platforms;update tests to use the former.

This is in line with 3994e8a9 (t4201: use ISO8859-1 rather than
ISO-8859-1, 2009-12-03), which did the same.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Reviewed-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05 00:05:00 -07:00
Brian Gernhardt
7c37521487 t4205: replace .\+ with ..* in sed commands
OS X's sed only accepts basic regular expressions, which does not
allow the + quantifier.  However '..*' (anything, followed by zero or
more anything) is the same as '.\+' (one or more anything) and valid
in any regular expression language.

Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-01 12:28:06 -07:00
Alexey Shumkin
ecaee8050c pretty: --format output should honor logOutputEncoding
One can set an alias
	$ git config [--global] alias.lg "log --graph --pretty=format:'%Cred%h%Creset
	-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
	--abbrev-commit --date=local"

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

	$ git log --oneline --no-color
	$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats "%s".

The same corruption is true for
	$ git diff --submodule=log
and
	$ git rev-list --pretty=format:%s HEAD
and
	$ git reset --hard

This patch makes pretty --format honor logOutputEncoding when it formats
log message.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26 11:40:31 -07:00
Alexey Shumkin
de6029a2d7 pretty: Add failing tests: --format output should honor logOutputEncoding
One can set an alias
	$ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
	-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
	--abbrev-commit --date=local"

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

	$ git log --oneline --no-color
	$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats "%s".

The same corruption is true for
	$ git diff --submodule=log
and
	$ git rev-list --pretty=format:%s HEAD
and
	$ git reset --hard

This patch adds failing tests for the next patch that fixes them.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26 11:40:27 -07:00
Alexey Shumkin
a742f2a0a7 t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26 11:33:00 -07:00
Nguyễn Thái Ngọc Duy
1640632b4f pretty: support %>> that steal trailing spaces
This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not
use up all 100 columns and %an needs more than 20 columns. By
replacing %>(20) with %>>(20), %an can steal spaces from %s.

%>> understands escape sequences, so %Cred does not stop it from
stealing spaces in %<(100).

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18 16:28:29 -07:00
Nguyễn Thái Ngọc Duy
a7f01c6b4d pretty: support truncating in %>, %< and %><
%>(N,trunc) truncates the right part after N columns and replace the
last two letters with "..". ltrunc does the same on the left. mtrunc
cuts the middle out.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18 16:28:29 -07:00
Nguyễn Thái Ngọc Duy
a57523428b pretty: support padding placeholders, %< %> and %><
Either %<, %> or %>< standing before a placeholder specifies how many
columns (at least as the placeholder can exceed it) it takes. Each
differs on how spaces are padded:

  %< pads on the right (aka left alignment)
  %> pads on the left (aka right alignment)
  %>< pads both ways equally (aka centered)

The (<N>) follows them, e.g. `%<(100)', to specify the number of
columns the next placeholder takes.

However, if '|' stands before (<N>), e.g. `%>|(100)', then the number
of columns is calculated so that it reaches the Nth column on screen.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18 16:28:29 -07:00
Linus Torvalds
74faaa16f0 Fix "git diff --stat" for interesting - but empty - file changes
The behavior of "git diff --stat" is rather odd for files that have
zero lines of changes: it will discount them entirely unless they were
renames.

Which means that the stat output will simply not show files that only
had "other" changes: they were created or deleted, or their mode was
changed.

Now, those changes do show up in the summary, but so do renames, so
the diffstat logic is inconsistent. Why does it show renames with zero
lines changed, but not mode changes or added files with zero lines
changed?

So change the logic to not check for "is_renamed", but for
"is_interesting" instead, where "interesting" is judged to be any
action but a pure data change (because a pure data change with zero
data changed really isn't worth showing, if we ever get one in our
diffpairs).

So if you did

   chmod +x Makefile
   git diff --stat

before, it would show empty (" 0 files changed"), with this it shows

 Makefile | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

which I think is a more correct diffstat (and then with "--summary" it
shows *what* the metadata change to Makefile was - this is completely
consistent with our handling of renamed files).

Side note: the old behavior was *really* odd. With no changes at all,
"git diff --stat" output was empty. With just a chmod, it said "0
files changed". No way is our legacy behavior sane.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-17 11:50:50 -07:00
Jiang Xin
b354f11b59 Fix tests under GETTEXT_POISON on diffstat
Use the i18n-specific test functions in test scripts for diffstat.
This issue was was introduced in v1.7.9-1-g7f814:

    7f814 Use correct grammar in diffstat summary line

and been broken under GETTEXT_POISON=YesPlease since.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 09:26:30 -07:00
Junio C Hamano
fafd38299b log-tree: the previous one is still not quite right
The correct output would have NUL after each commit, so "-z --format=%s"
would have a single-liner subject with the line-terminating LF replaced
with NUL, and "-p/--stat -z --format=%s" would have a single-liner subject
with its line-terminating LF, followed by the diff/diffstat in which the
terminating LF of the last line is replaced with NUL, but to be consistent
with what "-p/--stat -z --pretty=format:%s" does, I think it is OK to
append NUL to the diff/diffstat part instead of replacing its last LF with
NUL.

The added test shows the update is still not right for "-p -z --format".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-01 10:29:50 -07:00
Jan Krüger
3e065308ca log-tree: use custom line terminator in line termination mode
When using a custom format in line termination mode (as opposed to line
separation mode), the configured line terminator is not used, so things
like "git log --pretty=tformat:%H -z" do not work properly.

Make it use the line terminator the user ordered.

Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-01 09:56:37 -07:00
Dmitry Ivankov
7be8b3baba Fix typo: existant->existent
refs.c had a error message "Trying to write ref with nonexistant object".
And no tests relied on the wrong spelling.
Also typo was present in some test scripts internals, these tests still pass.

Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16 10:33:50 -07:00
Will Palmer
8028184eec pretty: add aliases for pretty formats
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 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 <wmpalmer@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-03 09:40:32 -07:00