commit c9bfb953 (want_color: automatically fallback to color.ui,
2011-08-17) introduced a regression where format-patch produces colorized
patches when color.ui is set to "always".
In f3aafa4 (Disable color detection during format-patch, 2006-07-09),
git_format_config was taught to intercept diff.color to avoid passing it
down to git_log_config and later, git_diff_ui_config.
Teach git_format_config to intercept color.ui in the same way.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of the "do we want color" flags default to -1 to
indicate that we don't have any color configured. This value
is handled in one of two ways:
1. In porcelain, we check early on whether the value is
still -1 after reading the config, and set it to the
value of color.ui (which defaults to 0).
2. In plumbing, it stays untouched as -1, and want_color
defaults it to off.
This works fine, but means that every porcelain has to check
and reassign its color flag. Now that want_color gives us a
place to put this check in a single spot, we can do that,
simplifying the calling code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit simply hijacked --quiet and essentially made it into a
no-op. Instead, take it as a cue that the end user wants to omit the patch
output from commands that default to show patches, e.g. "show".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In older versions of git, we used rfc822 header folding to
indicate that the original subject line had multiple lines
in it. But since a1f6baa (format-patch: wrap long header
lines, 2011-02-23), we now use header folding whenever there
is a long line.
This means that "git am" cannot trust header folding as a
sign from format-patch that newlines should be preserved.
Instead, format-patch needs to signal more explicitly that
the newlines are significant. This patch does so by
rfc2047-encoding the newlines in the subject line. No
changes are needed on the "git am" end; it already decodes
the newlines properly.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a pretty_print_context representing the parameters
for a pretty-print session, but we did not use it uniformly.
As a result, functions kept growing more and more arguments.
Let's clean this up in a few ways:
1. All pretty-print pp_* functions now take a context.
This lets us reduce the number of arguments to these
functions, since we were just passing around the
context values separately.
2. The context argument now has a cmit_fmt field, which
was passed around separately. That's one less argument
per function.
3. The context argument always comes first, which makes
calling a little more uniform.
This drops lines from some callers, and adds lines in a few
places (because we need an extra line to set the context's
fmt field). Overall, we don't save many lines, but the lines
that are there are a lot simpler and more readable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many callers don't actually care about the pretty print
context at all; let's just give them a simple way of
pretty-printing a commit without having to create a context
struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add log.abbrevCommit config variable as a convenience for users who
often use --abbrev-commit with git log and friends. Allow the option
to be overridden with --no-abbrev-commit. Per 635530a2fc and 4f62c2bc57,
the config variable is ignored when log is given "--pretty=raw".
(Also, a drive-by spelling correction in git log's short help.)
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use parse-options in cmd_log_init instead of manually iterating
through them. This makes the code a bit cleaner but more importantly
allows us to catch the "--quiet" option which causes some of the
log-related commands to misbehave as it would otherwise get passed on
to the diff.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --quiet flag is not meant to be passed on to the diff, as the user
always wants the patches to be produced so catch it and pass it to
reopen_stdout which decides whether to print the filename or not.
Noticed by Paul Gortmaker
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, "git reflog" overrides some command line options such as
"--format".
Fix this by using the new 2-phase version of cmd_log_init().
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cmd_log_init() sets up some default rev options and then calls
setup_revisions(), so that a caller cannot set up own defaults: Either
they get overriden by cmd_log_init() (if set before) or they override
the command line (if set after). We even complain about this in a
comment to cmd_log_reflog().
Therefore, separate the two steps so that one can still call
cmd_log_init() or, alternatively, cmd_log_init_defaults() followed by
cmd_log_init_finish() (and set defaults in between).
No functional change so far.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch changes behavior of the two functions. Previously it does
prefix matching only. Now it can also do wildcard matching.
All callers are updated. Some gain wildcard matching (archive,
checkout), others reset pathspec_item.has_wildcard to retain old
behavior (ls-files, ls-tree as they are plumbing).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce --min-parents and --max-parents options which limit the
revisions to those commits which have at least (or at most) that many
commits, where negative arguments for --max-parents= denote infinity
(i.e. no upper limit).
In particular:
--max-parents=1 is the same as --no-merges;
--min-parents=2 is the same as --merges;
--max-parents=0 shows only roots; and
--min-parents=3 shows only octopus merges
Using --min-parents=n and --max-parents=m with n>m gives you what you ask
for (i.e. nothing) for obvious reasons, just like when you give --merges
(show only merge commits) and --no-merges (show only non-merge commits) at
the same time.
Also, introduce --no-min-parents and --no-max-parents to do the obvious
thing for convenience.
We compute the number of parents only when we limit by that, so there
is no performance impact when there are no limiters.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there are too many paths in the project, the number of rename source
candidates "git diff -C -C" finds will exceed the rename detection limit,
and no inexact rename detection is performed. We however could fall back
to "git diff -C" if the number of modified paths is sufficiently small.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Readers uninterested in the details of "git cherry"'s output format
can see
print_commit('-', commit, verbose, abbrev);
and ignore the details.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the "--name-only/--name-status/--check does not make sense"
messages. A test in t4014-format-patch.sh explicitly checked for these
messages. Change them to skip under GETTEXT_POISON=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --max-count limit is implemented by counting revisions in
get_revision(), but the -S and -G take effect later when running diff.
Hence "--max-count=10 -Sfoo" meant "examine the 10 first revisions, and
out of them, show only those changing the occurences of foo", not "show 10
revisions changing the occurences of foo".
In case the commit isn't actually shown, cancel the decrement of
max_count.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass output through the pager if format-patch is run with --stdout. This
saves the user the trouble of running git with '-p' or piping through a
pager.
setup_pager() already checks if stdout is a tty, so we don't have to
worry about behaviour if the user redirects/pipes stdout. Paging can
also be disabled with the config
[pager]
format-patch = false
Add tests to check for these behaviour.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allows better help text to be defined than "be verbose". Also make use
of the macro in places that already had a different description. No
object code changes intended.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin/commit.c: Replace block of code with a one-liner call to
logmsg_reencode().
* commit.c: new function for looking up a comit by name
* pretty.c: helper methods for getting output encodings
Add helpers get_log_output_encoding() and
get_commit_output_encoding() that eliminate some messy and duplicate
if-blocks.
Signed-off-by: Pat Notz <patnotz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the topmost three commits in a branch were merge commits, 'git
format-patch -3' used to output nothing. Since Git can't prepare
patches out of merge commits anyway, don't go over them in the first
place. 'git format-patch -3' now prepares three patches from the
topmost three commits without counting merge commits. Also add a
corresponding test in t4014-format-patch and update documentation.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We start the pager too early for several git commands, which results in
the errors sometimes going to the pager rather than show up as errors.
This is often hidden by the fact that we pass in '-X' to less by default,
which causes 'less' to exit for small output, but if you do
export LESS=-S
you can then clearly see the problem by doing
git log --prretty
which shows the error message ("fatal: unrecognized argument: --prretty")
being sent to the pager.
This happens for pretty much all git commands that use USE_PAGER, and then
check arguments separately. But "git diff" does it too early too (even
though it does an explicit setup_pager() call)
This only fixes it for the trivial "git log" family case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the definition and callers of string_list_append to use the
string_list as the first argument. This helps make the string_list
API easier to use by being more consistent.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, git uses the version string as the signature for all
patches output by format-patch. Many employers (mine included)
require the use of a signature on all outgoing mails. In a
format-patch | send-email workflow there isn't an easy way to modify
the signature without breaking the pipe and manually replacing the
version string with the signature required. Instead of doing all that
work, add an option (--signature) and a config variable
(format.signature) to replace the default git version signature when
formatting patches.
This does modify the original behavior of format-patch a bit. First
off the version string is now placed in the cover letter by default.
Secondly, once the configuration variable format.signature is added
to the .config file there is no way to revert back to the default
git version signature. Instead, specifying the --no-signature option
will remove the signature from the patches entirely.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using git log --pretty='%N' without an explicit --show-notes, git
would segfault. This patches fixes this behaviour by loading the needed
notes datastructures if --pretty is used and the format contains %N.
When --pretty='%N' is used together with --no-notes, %N won't be
expanded.
This is an extension to a proposed patch by Jeff King.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of
[torvalds@nehalem git]$ em buil<tab>
Display all 180 possibilities? (y or n)
[torvalds@nehalem git]$ em builtin-sh
builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c
builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o
[torvalds@nehalem git]$ em builtin-shor<tab>
builtin-shortlog.c builtin-shortlog.o
[torvalds@nehalem git]$ em builtin-shortlog.c
you get
[torvalds@nehalem git]$ em buil<tab> [type]
builtin/ builtin.h
[torvalds@nehalem git]$ em builtin [auto-completes to]
[torvalds@nehalem git]$ em builtin/sh<tab> [type]
shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o
[torvalds@nehalem git]$ em builtin/sho [auto-completes to]
[torvalds@nehalem git]$ em builtin/shor<tab> [type]
shortlog.c shortlog.o
[torvalds@nehalem git]$ em builtin/shortlog.c
which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.
NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead. I think bash has some cut-off
around 100 choices or something.
So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion. But you can
simulate that by using 'ls' instead, or something similar.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration is meant to suppliment --decorate command line option
that can be used as a boolean to turn the feature on, so it is natural
to expect
[log]
decorate
decorate = yes
to work. The original commit would segfault with the first one, and
would not understand the second one.
Once a user has this configuration in ~/.gitconfig, there needs to be a
way to override it from the command line. Add --no-decorate option to
log family and also allow --decorate=no to mean the same thing. Since
we allow setting log.decorate to 'true', the command line also should
accept --decorate=yes and behave accordingly.
New tests in t4202 are designed to exercise the interaction between the
configuration variable and the command line option that overrides it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This alows the 'git-log --decorate' to be enabled by default so that normal
log outout contains ant ref names of commits that are shown.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Giving "Notes" information in the default output format of "log" and
"show" is a sensible progress (the user has asked for it by having the
notes), but for some commands (e.g. "format-patch") spewing notes into the
formatted commit log message without being asked is too aggressive.
Enable notes output only for "log", "show", "whatchanged" by default and
only when the user didn't ask any specific --pretty/--format from the
command line; users can explicitly override this default with --show-notes
and --no-notes option.
Parts of tests are taken from Jeff King's fix.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When given a pathspec that does not match any path in the current work
tree with an explicit "--":
git format-patch <commit> -- <path>
the command still complains that <path> does not exist in the current work
tree and the user needs to explicitly specify "--" and errors out. This
is because it incorrectly removes "--" from the command line arguments
that is later passed to setup_revisions().
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no need for "git <command> -h" to depend on being inside
a repository.
Reported by Gerfried Fuchs through http://bugs.debian.org/462557
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"-p" means "generate patch" in 'git log' and 'git diff', so it's
quite surprising that it means "suppress diffstat" in
'git format-patch'.
Keep the "-p" option for backward compatibility, but add
"--no-stat" as a more intuitive synonym. For backward compatibility
with scripts, we must allow combinations of --stat and --no-stat.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King recently reinstated -p to suppress the default diffstat
(as -p used to work before 68daa64, about 14 months ago).
However, -p is also needed in combination with certain options
(e.g. --stat or --numstat) in order to produce any patch at all.
The documentation does not mention this.
Since the purpose of format-patch is to produce a patch that
can be emailed, it does not make sense that certain combination
of options will suppress the generation of the patch itself.
Therefore:
* Update 'git format-patch' to always generate a patch.
* Since the --name-only, --name-status, and --check suppresses
the generation of the patch, disallow those options,
and remove the description of them in the documentation.
* Remove the reference to -p in the description of -U.
* Remove the descriptions of the options that are synonyms for -p
plus another option (--patch-with-raw and --patch-with-stat).
* While at it, slightly tweak the description of -p itself
to say that it generates "plain patches", so that you can
think of -p as "plain patch" as an mnemonic aid.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Treat an "-h" option as a request for help, rather than an
"Unknown commit -h" error.
"cherry -h" could be asking to compare histories that leads to
our HEAD and a commit that can be named as "-h". Strictly
speaking, that may be a valid refname, but the user would have to
say something like "tags/-h" to name such a pathological ref
already, so it is not such a big deal.
The "-h" option keeps its meaning even if preceded by other
options or followed by other arguments. This keeps the
command-line syntax closer to what parse_options would give and
supports shell aliases like 'alias cherry="git cherry -v"' a
little better.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once upon a time, format-patch would use its default stat
plus patch format only when no diff format was given on the
command line. This meant that "format-patch -p" would
suppress the stat and show just the patch.
Commit 68daa64 changed this to keep the stat format when we
had an "implicit" patch format, like "-U5". As a side
effect, this meant that an explicit patch format was now
ignored (because cmd_format_patch didn't know the reason
that the format was set way down in diff_opt_parse).
This patch unbreaks what 68daa64 did (while still preserving
what 68daa64 was trying to do), reinstating "-p" to suppress
the default behavior. We do this by parsing "-p" ourselves
in format-patch, and noting whether it was used explicitly.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty_print_commit() has a bunch of rarely-used arguments, and
introducing more of them requires yet another update of all the call
sites. Refactor most of them into a struct to make future extensions
easier.
The ones that stay "plain" arguments were chosen on the grounds that
all callers put real arguments there, whereas some callers have 0/NULL
for all arguments that were factored into the struct.
We declare the struct 'const' to ensure none of the callers are bitten
by the changed (no longer call-by-value) semantics.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.
This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.
This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If your name is, say, Üwë, you want your cover letters to appear
correctly. Convince format-patch to mark it as 8-bit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option "QUIET" primarily meant "find if we have _any_ difference as
quick as possible and report", which means we often do not even have to
look at blobs if we know the trees are different by looking at the higher
level (e.g. "diff-tree A B"). As a side effect, because there is no point
showing one change that we happened to have found first, it also enables
NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet.
Rename the internal option to QUICK to reflect this better; it also makes
grepping the source tree much easier, as there are other kinds of QUIET
option everywhere.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When showing an annotated tag, "git show" will always
display the pointed-to object. However, it didn't separate
the two with whitespace, making it more difficult to notice
where the new object started. For example:
$ git tag -m 'my message' foo
$ git show foo
tag foo
Tagger: Jeff King <peff@peff.net>
Date: Fri Jul 17 18:46:25 2009 -0400
my message
commit 41cabf8fed2694ba33e01d64f9094f2fc5e5805a
Author: Jeff King <peff@peff.net>
Date: Thu Jul 16 17:31:34 2009 -0400
...
This patch respects and sets the rev.shown_one member to
prepend a blank line before showing a second item. We use
this member of rev_info instead of a local flag, because the
log_tree_commit we call into for showing commits already
respects and sets that flag. Meaning that everything will be
spaced properly if you intermix commits and tags, like:
$ git show v1.6.3 v1.6.2 HEAD
In that case, a single blank line will separate the first
tag, the commit it points to, the second tag, the commit
that one points to, and the final commit.
While we're at it, let's also support trees, so that even
something as crazy as
$ git show HEAD^{tree} HEAD~1^{tree} HEAD
will also be spaced in an easy-to-read way. However, we
intentionally do _not_ insert blank lines for blobs, so
that specifying multiple blobs gives a strict concatenation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When showing a tag, our header parsing finishes with the
offset pointing to the newline separating the tag header
from the tag body. This means that the printed body will
always start with a newline.
However, we also add an extra newline when printing the
tagger information. This leads to an ugly double-newline:
$ git show v1.6.3
tag v1.6.3
Tagger: Junio C Hamano <gitster@pobox.com>
Date: Wed May 6 18:16:47 2009 -0700
GIT 1.6.3
-----BEGIN PGP SIGNATURE-----
...
This patch removes the extra newline from the end of the
tagger headers. This is a better solution than suppressing
the separator newline, because it retains the behavior for
tags which have no tagger. E.g., "git show v0.99" will
continue to look like:
$ git show v0.99
tag v0.99
Test-release for wider distribution.
...
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lots of die() calls did not actually report the kind of error, which
can leave the user confused as to the real problem. Use die_errno()
where we check a system/library call that sets errno on failure, or
one of the following that wrap such calls:
Function Passes on error from
-------- --------------------
odb_pack_keep open
read_ancestry fopen
read_in_full xread
strbuf_read xread
strbuf_read_file open or strbuf_read_file
strbuf_readlink readlink
write_in_full xwrite
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pang Yan Han