Merge branch 'mg/doc-remote-tags-or-not' into maint
"git remote add" mentioned "--tags" and "--no-tags" and was not
clear that fetch from the remote in the future will use the default
behaviour when neither is given to override it.
* mg/doc-remote-tags-or-not:
git-remote.txt: describe behavior without --tags and --no-tags
Merge branch 'mk/diff-shortstat-dirstat-fix' into maint
"git diff --shortstat --dirstat=changes" showed a dirstat based on
lines that was never asked by the end user in addition to the
dirstat that the user asked for.
"git apply" was not very careful about reading from, removing,
updating and creating paths outside the working tree (under
--index/--cached) or the current directory (when used as a
replacement for GNU patch).
* jc/apply-beyond-symlink:
apply: do not touch a file beyond a symbolic link
apply: do not read from beyond a symbolic link
apply: do not read from the filesystem under --index
apply: reject input that touches outside the working area
The "interpolated-path" option of "git daemon" inserted any string
client declared on the "host=" capability request without checking.
Sanitize and limit %H and %CH to a saner and a valid DNS name.
* jk/daemon-interpolate:
daemon: sanitize incoming virtual hostname
t5570: test git-daemon's --interpolated-path option
git_connect: let user override virtual-host we send to daemon
We create 50,000 tags to check that we don't overflow the
command-line of fetch-pack. But by using run_with_cmdline_limit,
we can get the same effect with a much smaller number of
tags. This makes the test fast enough that we can drop the
EXPENSIVE prereq, which means people will actually run it.
It was not documented to do so, but this test was also the
only test of a clone-over-http that requires multiple POSTs
during the conversation. We can continue to test that by
dropping http.postbuffer to its minimum size, and checking
that we get two POSTs.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apache removes GIT_TRACE from the environment before running
git-http-backend. This can make it hard to debug the server
side of an http session. Let's let it through.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
you may get test failures, because some tests capture and
check the stderr output from git commands (and with
GIT_TRACE set to 1, the trace output will be included
there).
When we see GIT_TRACE set like this, we print a warning to
the user. However, we can do even better than that by just
pointing it to descriptor 4, which all tests leave connected
to the test script's stderr. That's likely what the user
intended (and any scripts that do want to see GIT_TRACE
output will set GIT_TRACE themselves).
Not only does this avoid false negatives in the tests, but
it means the user will actually see trace output for git
calls that redirect their stderr (whereas before, it was
sometimes confusingly buried in a file).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now if a test script receives SIGINT (e.g., because a
test was hanging and the user hit ^C), the shell exits
immediately. This can be annoying if the test script did any
global setup, like starting apache or git-daemon, as it will
not have an opportunity to clean up after itself. A
subsequent run of the test won't be able to start its own
daemon, and will either fail or skip the tests.
Instead, let's trap SIGINT to make sure we do a clean
shutdown, and just chain it to a normal exit (which will
trigger any cleanup).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack: do not check NULL return of lookup_unknown_object
We check whether the return value of lookup_unknown_object
is NULL, but some code paths dereference it before our
check. This turns out not to be capable of causing a
segfault, though. The lookup_unknown_object function will
never return NULL, since the whole point is to allocate an
object struct if it does not find an existing one. So the
code here is not wrong, it is just confusing. Let's just
drop the NULL check.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack: fix transfer.hiderefs over smart-http
When upload-pack advertises the refs (either for a normal,
non-stateless request, or for the initial contact in a
stateless one), we call for_each_ref with the send_ref
function as its callback. send_ref, in turn, calls
mark_our_ref, which checks whether the ref is hidden, and
sets OUR_REF or HIDDEN_REF on the object as appropriate. If
it is hidden, mark_our_ref also returns "1" to signal
send_ref that the ref should not be advertised.
If we are not advertising refs, (i.e., the follow-up
invocation by an http client to send its "want" lines), we
use mark_our_ref directly as a callback to for_each_ref. Its
marking does the right thing, but when it then returns "1"
to for_each_ref, the latter interprets this as an error and
stops iterating. As a result, we skip marking all of the
refs that come lexicographically after it. Any "want" lines
from the client asking for those objects will fail, as they
were not properly marked with OUR_REF.
To solve this, we introduce a wrapper callback around
mark_our_ref which always returns 0 (even if the ref is
hidden, we want to keep iterating). We also tweak the
signature of mark_our_ref to exclude unnecessary parameters
that were present only to conform to the callback interface.
This should make it less likely for somebody to accidentally
use it as a callback in the future.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported-by: "Mladen B." <mladen074@gmail.com> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7510: do not fail when gpg warns about insecure memory
Depending on how gpg was built, it may issue the following
message to stderr when run:
Warning: using insecure memory!
When the test is collecting gpg output it is therefore not
enough to just match on a "gpg: " prefix it must also match
on a "Warning: " prefix wherever it needs to match lines
that have been produced by gpg.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
imap-send: use cURL automatically when NO_OPENSSL defined
If both USE_CURL_FOR_IMAP_SEND and NO_OPENSSL are defined do
not force the user to add --curl to get a working git imap-send
command.
Instead automatically select --curl and warn and ignore the
--no-curl option. And while we're in there, correct the
warning message when --curl is requested but not supported.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git: treat "git -C '<path>'" as a no-op when <path> is empty
'git -C ""' unhelpfully dies with error "Cannot change to ''",
whereas the shell treats `cd ""' as a no-op. Taking the shell's
behavior as a precedent, teach git to treat `-C ""' as a no-op, as
well.
Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/simple-cleanups:
sha1_name: use strlcpy() to copy strings
pretty: use starts_with() to check for a prefix
for-each-ref: use skip_prefix() to avoid duplicate string comparison
connect: use strcmp() for string comparison
Merge branch 'km/send-email-getopt-long-workarounds' into maint
Even though we officially haven't dropped Perl 5.8 support, the
Getopt::Long package that came with it does not support "--no-"
prefix to negate a boolean option; manually add support to help
people with older Getopt::Long package.
* km/send-email-getopt-long-workarounds:
git-send-email.perl: support no- prefix with older GetOptions
The __git_remotes() helper function lists the remotes from the config
file by processing the output of a 'git config' query. A simple 'git
remote' produces the exact same output, so run that instead.
Remotes under '$GIT_DIR/remotes' are still listed by running 'ls -1',
because 'git remote' unfortunately ignores them.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10)
taught rebase-interactive to display an item count in the instruction
list comments:
# Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s))
#
# Commands:
# p, pick = use commit
# ...
However, with the exception of the --edit-todo option, "TODO" is a
one-off term, never presented to the user by rebase-interactive in
any other context. The item count is in fact the number of commands
("pick", "edit", etc.) remaining on the instruction sheet, and the
comment immediately following it talks about "Commands". Consequently,
replace "(# TODO item(s))" with the more accurate and meaningful
"(# command(s))".
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10)
taught rebase-interactive to compute an item count with 'wc -l' and
display it in the instruction list comments:
'was_alias' variable does not need to store it's value on each
iteration in the loop; this variable gets assigned the result
of run_argv() every time in the loop before being used.
'done_help' variable does not need to be static variable too if
we move it out the loop.
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'es/squelch-openssl-warnings-on-macosx' into maint
An earlier workaround to squelch unhelpful deprecation warnings
from the complier on Mac OSX unnecessarily set minimum required
version of the OS, which the user might want to raise (or lower)
for other reasons.
* es/squelch-openssl-warnings-on-macosx:
git-compat-util: do not step on MAC_OS_X_VERSION_MIN_REQUIRED
Longstanding configuration variable naming rules has been added to
the documentation.
* jc/conf-var-doc:
CodingGuidelines: describe naming rules for configuration variables
config.txt: mark deprecated variables more prominently
config.txt: clarify that add.ignore-errors is deprecated
Clarify in the documentation that "remote.<nick>.pushURL" and
"remote.<nick>.URL" are there to name the same repository accessed
via different transports, not two separate repositories.
* jc/remote-set-url-doc:
Documentation/git-remote.txt: stress that set-url is not for triangular
The tests that wanted to see that file becomes unreadable after
running "chmod a-r file", and the tests that wanted to make sure it
is not run as root, we used "can we write into the / directory?" as
a cheap substitute, but on some platforms that is not a good
heuristics. The tests and their prerequisites have been updated to
check what they really require.
* jk/sanity:
test-lib.sh: set prerequisite SANITY by testing what we really need
tests: correct misuses of POSIXPERM
t/lib-httpd: switch SANITY check for NOT_ROOT
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")" in color.diff.commit.
If you wanted to paint the HEAD and local branch name in the same
color as the body text (perhaps because cyan and green are too faint
on a black-on-white terminal to be readable), you would not want to
have to say
[color "decorate"]
head = black
branch = black
because that you would not be able to reuse same configuration on a
white-on-black terminal. You would naively expect
[color "decorate"]
head = normal
branch = normal
to work, but unfortunately it does not. It paints the string "HEAD"
and the branch name in the same color as the opening parenthesis or
comma between the decoration elements. This is because the code
forgets to reset the color after printing the "prefix" in its own
color.
It theoretically is possible that some people were expecting and
relying on that the attribute set as the "diff.commit" color, which
is used to draw these opening parenthesis and inter-item comma, is
inherited by the drawing of branch names, but it is not how the
coloring works everywhere else.
Documentation/config.txt: have a separate "Values" section
The various types of values set to the configuration variables
deserve more than a brief footnote mention in the syntax section,
and it will be more so after the later steps of this clean up
effort.
Move the mention of booleans from the syntax section to this new
section, and describe how human-readble integers can be spelled with
scaling there.
Documentation/config.txt: describe the structure first and then meaning
A line can be continued via a backquote-LF and can be chomped at a
comment character. But that is not specific to string-typed values.
It is common to all, just like unquoted leading and trailing
whitespaces are stripped and inter-word spacing are retained.
Move the description around and desribe these structural rules
first, then introduce the double-quote facility as a way to override
them, and finally mention various types of values.
Note that these structural rules only apply to the value part of the
configuration file. E.g.
[aSection] \
name \
= value
does not work, because the rules kick in only after seeing "name =".
Both the original and the updated text are phrased in an awkward way
by singling out the "value" part of the line because of this.
Documentation/config.txt: explain multi-valued variables once
The syntax section repeats what the preamble explained already.
That a variable can have multiple values is more about what a
variable is than the syntax of the file.
Section names and variable names are both case-insensitive, but one
is described as "not case sensitive". Use "case-insensitive" for
both.
Instead of saying "... have to be escaped" without telling what that
escaping achieves, state it in a more positive way, i.e. "... can be
included by escaping".
submodule: improve documentation of update subcommand
The documentation of 'git submodule update' has several problems:
1) It mentions that value 'none' of submodule.$name.update can be
overridden by --checkout, but other combinations of configuration
values and command line options are not mentioned.
2) The documentation of submodule.$name.update is scattered across three
places, which is confusing.
3) The documentation of submodule.$name.update in gitmodules.txt is
incorrect, because the code always uses the value from .git/config
and never from .gitmodules.
4) Documentation of --force was incomplete, because it is only effective
in case of checkout method of update.
Fix all these problems by documenting submodule.*.update in
git-submodule.txt and make everybody else refer to it.
Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
kwset: use unsigned char to store values with high-bit set
Sun Studio on Solaris issues warnings about improper initialization
values being used when defining tolower_trans_tbl[] in ctype.c. The
array wants to store values with high-bit set and treat them as
values between 128 to 255. Unlike the rest of the Git codebase
where we explicitly specify 'unsigned char' for such variables and
arrays, however, kwset code we borrowed from elsewhere uses 'char'
for this and other variables.
Fix the declarations to explicitly use 'unsigned char' where
necessary to bring it in line with the rest of the Git.
Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --shortstat is used in conjunction with --dirstat=changes, git diff will
output the dirstat information twice: first as calculated by the 'lines'
algorithm, then as calculated by the 'changes' algorithm:
The rename code cannot handle an input where we have
duplicate destinations (i.e., more than one diff_filepair in
the queue with the same string in its pair->two->path). We
end up allocating only one slot in the rename_dst mapping.
If we fill in the diff_filepair for that slot, when we
re-queue the results, we may queue that filepair multiple
times. When the diff is finally flushed, the filepair is
processed and free()d multiple times, leading to heap
corruption.
This situation should only happen when a tree diff sees
duplicates in one of the trees (see the added test for a
detailed example). Rather than handle it, the sanest thing
is just to turn off rename detection altogether for the
diff.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: split locate_rename_dst into two functions
This function manages the mapping of destination pathnames
to filepairs, and it handles both insertion and lookup. This
makes the return value a bit confusing, as we return a newly
created entry (even though no caller cares), and have no
room to indicate to the caller that an entry already
existed.
Instead, let's break this up into two distinct functions,
both backed by a common binary search. The binary search
will use our normal "return the index if we found something,
or negative index minus one to show where it would have
gone" semantics.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current help string is about --no-exclude-standard. But "git grep -h"
would show --exclude-standard instead. Flip the string. See 0a93fb8
(grep: teach --untracked and --exclude-standard options - 2011-09-27)
for more info about these options.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since b19138b (git-svn: Make it incrementally faster by minimizing temp
files, v1.6.0), git-svn has been using the Git.pm temp_acquire and
temp_release mechanism to avoid unnecessary temp file churn and provide
a speed boost.
However, that change introduced a call to temp_acquire inside the
Git::SVN::Fetcher::close_file function for an 'svn_hash' temp file.
Because an SVN::Pool is active at the time this function is called, if
the Git::temp_acquire function ends up actually creating a new
FileHandle for the temp file (which it will the first time it's called
with the name 'svn_hash') that FileHandle will end up in the SVN::Pool
and should that pool have SVN::Pool::clear called on it that FileHandle
will be closed out from under Git::temp_acquire.
Since the only call site to Git::temp_acquire with the name 'svn_hash'
is inside the close_file function, if an 'svn_hash' temp file is ever
created its FileHandle is guaranteed to be created in the active
SVN::Pool.
This has not been a problem in the past because the SVN::Pool was not
being cleared. However, since dfa72fdb (git-svn: reload RA every
log-window-size, v2.2.0) the pool has been getting cleared periodically
at which point the FileHandle for the 'svn_hash' temp file gets closed.
Any subsequent calls to Git::temp_acquire for 'svn_hash', however,
succeed without creating/opening a new temporary file since it still has
the now invalid FileHandle in its cache. Callers that then attempt to
use that FileHandle fail with an error.
We avoid this problem by making sure the 'svn_hash' temp file is created
in the same place the 'svn_delta_...' and 'git_blob_...' temp files are
(and then temp_release'd) so that it can be safely used inside the
close_file function without having its FileHandle end up in an SVN::Pool
that gets cleared.
Additionally the Git.pm cat_blob function creates a bidirectional pipe
FileHandle using the IPC::Open2::open2 function. If that handle is
created too late, it also gets caught up in the SVN::Pool and incorrectly
closed by the SVN::Pool::clear call. But this only seems to happen with
more recent versions of Perl and svn.
To avoid this problem we add an explicit call to _open_cat_blob_if_needed
before the first call to SVN::Pool->new_default to make sure the open2
handle does not end up in the SVN::Pool.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix localtime=true on non-glibc environments
git svn uses POSIX::strftime('%s', $sec, $min, ...) to make unix epoch time.
But lowercase %s formatting character is a GNU extention. This causes problem
in git svn fetch --localtime on non-glibc systems, such as msys or cygwin.
Using Time::Local::timelocal($sec, $min, ...) fixes it.
Signed-off-by: Ryuichi Kokubo <ryu1kkb@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
Notes:
lowercase %s format character in strftime is a GNU extension and not widely supported.
POSIX::strftime affected by underlying crt's strftime because POSIX::strftime just calls crt's one.
Time::Local is good function to replace POSIX::strftime because it's a perl core module function.
Document about Time::Local.
http://perldoc.perl.org/Time/Local.html
These are specifications of strftime.
The GNU C Library Reference Manual.
http://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time.html
perl POSIX module's strftime document. It does not have '%s'.
http://perldoc.perl.org/POSIX.html
strftime document of Microsort Windows C Run-Time library.
https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx
The Open Group's old specification does not have '%s' too.
http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html
On my environment, following problems happened.
- msys : git svn fetch does not progress at all with perl.exe consuming CPU.
- cygwin : git svn fetch progresses but time stamp information is dropped.
Every commits have unix epoch timestamp.
I would like to thank git developer and contibutors.
git helps me so much everyday.
Thank you.
Merge branch 'ak/add-i-empty-candidates' into maint
The interactive "show a list and let the user choose from it"
interface "add -i" used showed and prompted to the user even when
the candidate list was empty, against which the only "choice" the
user could have made was to choose nothing.
* ak/add-i-empty-candidates:
add -i: return from list_and_choose if there is no candidate
"git apply --whitespace=fix" used to under-allocate the memory
when the fix resulted in a longer text than the original patch.
* jc/apply-ws-fix-expands:
apply: count the size of postimage correctly
apply: make update_pre_post_images() sanity check the given postlen
apply.c: typofix
Merge branch 'mg/commit-author-no-match-malformed-message' into maint
The error message from "git commit", when a non-existing author
name was given as value to the "--author=" parameter, has been
reworded to avoid misunderstanding.
The documentation incorrectly said that C(opy) and R(ename) are the
only ones that can be followed by the score number in the output in
the --raw format.
* jc/diff-format-doc:
diff-format doc: a score can follow M for rewrite
Merge branch 'bc/http-fallback-to-password-after-krb-fails' into maint
After attempting and failing a password-less authentication
(e.g. kerberos), libcURL refuses to fall back to password based
Basic authentication without a bit of help/encouragement.
* bc/http-fallback-to-password-after-krb-fails:
remote-curl: fall back to Basic auth if Negotiate fails
Merge branch 'jn/rerere-fail-on-auto-update-failure' into maint
"git rerere" (invoked internally from many mergy operations) did
not correctly signal errors when told to update the working tree
files and failed to do so for whatever reason.
* jn/rerere-fail-on-auto-update-failure:
rerere: error out on autoupdate failure
"git blame HEAD -- missing" failed to correctly say "HEAD" when it
tried to say "No such path 'missing' in HEAD".
* jk/blame-commit-label:
blame.c: fix garbled error message
use xstrdup_or_null to replace ternary conditionals
builtin/commit.c: use xstrdup_or_null instead of envdup
builtin/apply.c: use xstrdup_or_null instead of null_strdup
git-compat-util: add xstrdup_or_null helper
test_ln_s_add: refresh stat info of fake symbolic links
We have a helper function test_ln_s_add that inserts a symbolic link
into the index even if the file system does not support symbolic links.
There is a small flaw in the emulation path: the added entry does not
pick up stat information of the fake symbolic link from the file system,
as a consequence, the index is not exactly the same as for the "regular"
path (where symbolic links are available). To fix this, just call
git update-index again.
This flaw was revealed by the earlier change that tightened
compare_diff_raw(), because a test case in t4008 depends on the
correctly updated index.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 3a0a3a89 ("git-compat-util.h: don't define _XOPEN_SOURCE
on cygwin", 23-11-2014) removed the definition of _XOPEN_SOURCE on
cygwin, the code within a pre-processor conditional further down the
file became redundant. Remove the redundant code.
This effectively reverts commit 41b20017 ("Fix an "implicit function
definition" warning", 03-03-2007).
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The URL for ssh may have include a username before the hostname,
like ssh://user@host/repo.
When literal IPV6 addresses are used together with a username,
the substring "user@[::1]" must be converted into "user@::1".
Make that conversion visible for the user, and write userandhost
in the diagnostics
Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test the parsing of literall IPV6 addresses more systematically:
- with and without brackets (e.g. ::1 [::1])
- with brackets and port number: (e.g. [::1]:22)
- with username (e.g. user@::1)
- with username and brackets:
Because user@[::1] was not supported on older Git version,
[user@::1] had to be used as a workaround.
Test that user@::1 user@[::1] and [user@::1] all do the same.
Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ssh:// syntax was added in 2386d658 (Add first cut at "git
protocol" connect logic., 2005-07-13), it accepted
ssh://user@2001:db8::1/repo.git, which is now legacy.
Over the years the parser was improved to support [] and port numbers,
but the combination of ssh://user@[2001:db8::1]:222/repo.git did
never work.
The only only way to use a user name, a literall IPV6 address and a port
number was ssh://[user@2001:db8::1]:222/repo.git
(Thanks to Christian Taube <lists@hcf.yourweb.de> for reporting this long
standing issue)
New users would use ssh://user@[2001:db8::1]:222/repo.git,
so change the parser to handle it correctly.
Support the old legacy URLs as well, to be backwards compatible,
and avoid regressions for users which upgrade an existing installation
to a later Git version.
Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use strlcpy() instead of calling strncpy() and then setting the last
byte of the target buffer to NUL explicitly. This shortens and
simplifies the code a bit.
Signed-of-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
for-each-ref: use skip_prefix() to avoid duplicate string comparison
Use skip_prefix() to get the part after "color:" (if present) and only
compare it with "reset" instead of comparing the whole string again.
This gets rid of the duplicate "color:" part of the string constant.
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The variable was documented in git-mailinfo.txt, but not in config.txt.
The detailed documentation is still the one of --scissors in
git-mailinfo.txt, but we give enough information here to let the user
understand what it is about, and to make it easy to find it (e.g.
searching ">8" and "8<" finds it).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>