* tb/document-status-u-tradeoff:
status: advise to consider use of -u when read_directory takes too long
git status: document trade-offs in choosing parameters to the -u option
* da/downcase-u-in-usage:
contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
contrib/examples/git-remote.perl: use a lowercase "usage:" string
tests: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
Documentation/user-manual.txt: use a lowercase "usage:" string
templates/hooks--update.sample: use a lowercase "usage:" string
contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
contrib/examples: use a lowercase "usage:" string
contrib/fast-import/import-zips.py: use spaces instead of tabs
contrib/fast-import/import-zips.py: fix broken error message
contrib/fast-import: use a lowercase "usage:" string
contrib/credential: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsexportcommit: use a lowercase "usage:" string
git-archimport: use a lowercase "usage:" string
git-merge-one-file: use a lowercase "usage:" string
git-relink: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
git-sh-setup: use a lowercase "usage:" string
After commit cbfd5e1c ("drop some obsolete "x = x" compiler warning
hacks", 21-03-2013) removed a gcc specific hack, older versions of
gcc now issue an "'contents' might be used uninitialized" warning.
In order to suppress the warning, we simply initialize the variable
to NULL in it's declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit cbfd5e1c ("drop some obsolete "x = x" compiler warning hacks",
21-03-2013) removed a gcc hack that suppressed an "might be used
uninitialized" warning issued by older versions of gcc.
However, commit 3aa99df8 ('fast-import: clarify "inline" logic in
file_change_m', 21-03-2013) addresses an (almost) identical issue
(with very similar code), but includes additional code in it's
resolution. The solution used by this commit, unlike that used by
commit cbfd5e1c, also suppresses the -Wuninitialized warning on
older versions of gcc.
In order to suppress the warning (against the 'oe' symbol) in the
note_change_n() function, we adopt the same solution used by commit
3aa99df8.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"insn" appears to be an in-code abbreviation and should not appear
in manual/help pages.
Signed-off-by: Matthias Krüger <matthias.krueger@famsik.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calculating whether there is a d/f conflict, the calculation of
whether both sides are directories generates an incorrect references
mask because it does not use the loop index to set the correct bit.
Fix this typo.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The text is copied from Documentation/git-tag.txt.
Signed-off-by: Christian Helmuth <christian.helmuth@genode-labs.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git submodule update", when recursed into sub-submodules, did not
acccumulate the prefix paths.
* we/submodule-update-prefix-output:
submodule update: when using recursion, show full path
Sort filenames read from the maildir/ in a way that is more likely
to sort messages in the order the writing MUA meant to, by sorting
numeric segment in numeric order and non-numeric segment in
alphabetical order.
* jk/mailsplit-maildir-muttsort:
mailsplit: sort maildir filenames more cleverly
When export-subst is used, "zip" output recorded incorrect
size of the file.
* rs/zip-compresssed-size-with-export-subst:
archive-zip: fix compressed size for stored export-subst files
Some platforms and users spell UTF-8 differently; retry with the
most official "UTF-8" when the system does not understand the
user-supplied encoding name that are the common alternative
spellings of UTF-8.
* jk/utf-8-can-be-spelled-differently:
utf8: accept alternate spellings of UTF-8
"git branch" had more cases where it did not bother to check
nonsense command line parameters.
* nd/branch-error-cases:
branch: segfault fixes and validation
perl/Git.pm::cat_blob slurped everything in core only to write it
out to a file descriptor, which was not a very smart thing to do.
* jc/perl-cat-blob:
Git.pm: fix cat_blob crashes on large files
Correctly connect to SSL/TLS sites that serve multiple hostnames on
a single IP by including Server Name Indication in the client-hello.
* ob/imap-send-ssl-verify:
imap-send: support Server Name Indication (RFC4366)
In "git reflog expire", REACHABLE bit was not cleared from the
correct objects.
* jc/maint-reflog-expire-clean-mark-typofix:
reflog: fix typo in "reflog expire" clean-up codepath
In particular, it can get called with four arguments if you happen to
be referring to a repo using the ssh:// scheme with a non-default port
number.
Signed-off-by: Dan Bornstein <danfuzz@milk.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the v1.8.0 era, we changed symbols that do not have to be global
to file scope static, but a few functions in graph.c were used by
CGit from sideways bypassing the entry points of the API the
in-tree users use.
* jk/graph-c-expose-symbols-for-cgit:
Revert "graph.c: mark private file-scope symbols as static"
* maint-1.8.1:
bundle: Add colons to list headings in "verify"
bundle: Fix "verify" output if history is complete
Documentation: filter-branch env-filter example
git-filter-branch.txt: clarify ident variables usage
git-compat-util.h: Provide missing netdb.h definitions
describe: Document --match pattern format
Documentation/githooks: Explain pre-rebase parameters
update-index: list supported idx versions and their features
diff-options: unconfuse description of --color
read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr()
index-format.txt: mention of v4 is missing in some places
"git bundle verify" did not say "records a complete history" for a
bundle that does not have any prerequisites.
* lf/bundle-verify-list-prereqs:
bundle: Add colons to list headings in "verify"
bundle: Fix "verify" output if history is complete
Add an example use of "--env-filter" in "filter-branch"
documentation.
* tk/doc-filter-branch:
Documentation: filter-branch env-filter example
git-filter-branch.txt: clarify ident variables usage
Some sources failed to compile on systems that lack NI_MAXHOST in
their system header.
* dm/ni-maxhost-may-be-missing:
git-compat-util.h: Provide missing netdb.h definitions
The "--match=<pattern>" argument "git describe" takes uses glob
pattern but it wasn't obvious from the documentation.
* gp/describe-match-uses-glob-pattern:
describe: Document --match pattern format
The v4 index format was not documented.
* nd/doc-index-format:
update-index: list supported idx versions and their features
read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr()
index-format.txt: mention of v4 is missing in some places
The "--color=<when>" argument to the commands in the diff family
was described poorly.
* jc/color-diff-doc:
diff-options: unconfuse description of --color
To a human reader, it is quite obvious that cmp is assigned before
it is used, but gcc 4.6.3 that ships with Ubuntu 12.04 is among
those that do not get this right.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always create a merge commit even if fast-forward was possible.
It's like having --no-ff present on the command line.
It's a difference from the default behavior described in git-merge.txt.
It should be documented as an exception of "FAST-FORWARD MERGE" section
and "--ff" option description.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before talking about notations such as optional [--option] enclosed
in brackets, state that the documents are in AsciiDoc and processed
into other formats.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the warning message printed when rename or unmodified copy
detection was skipped due to too many files, change "diff.renamelimit"
to "diff.renameLimit", in order to make it consistent with git
documentation, which consistently uses "diff.renameLimit".
Signed-off-by: Max Nanasy <max.nanasy@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In wt_status_print_change_data, we accept a change_type flag
that is meant to be either WT_STATUS_UPDATED or
WT_STATUS_CHANGED. We then switch() on this value to set
the local variable "status" for each case, but do not
provide a fallback "default" label to the switch statement.
As a result, the compiler realizes that "status" might be
unset, and complains with a warning. To silence this
warning, we use the "int status = status" trick. This is
correct with the current code, as all callers provide one of
the two expected change_type flags. However, it's also a
maintenance trap, as there is nothing to prevent future
callers from passing another flag, nor to document this
assumption.
Instead of using the "x = x" hack, let's handle the default
case in the switch() statement with a die("BUG"). That tells
the compiler and any readers of the code exactly what the
function's input assumptions are.
We could also convert the flag to an enum, which would
provide a compile-time check on the function input. However,
since these flags are part of a larger enum, that would make
the code unnecessarily complex (we would have to make a new
enum with just the two flags, and then convert it to the old
enum for passing to sub-functions).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we read a fast-import line like:
M 100644 :1 foo.c
we point the local object_entry variable "oe" to the object
named by the mark ":1". When the input uses the "inline"
construct, however, we do not have such an object_entry.
The current code is careful not to access "oe" in the inline
case, but we can make the assumption even more obvious (and
catch violations of it) by setting oe to NULL and adding a
comment. As a bonus, this also squelches an over-zealous gcc
-Wuninitialized warning, which means we can drop the "oe =
oe" initialization hack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we fail to fork, we set the failed_errno variable to
the value of errno so it is not clobbered by later syscalls.
However, we do so in a conditional, and it is hard to see
later under what conditions the variable has a valid value.
Instead of setting it only when fork fails, let's just
always set it after forking. This is more obvious for human
readers (as we are no longer setting it as a side effect of
a strerror call), and it is more obvious to gcc, which no
longer generates a spurious -Wuninitialized warning. It also
happens to match what the WIN32 half of the #ifdef does.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to 47ec794, this initialization is meant to
squelch an erroneous uninitialized variable warning from gcc
4.0.1. That version is quite old at this point, and gcc 4.1
and up handle it fine, with one exception. There seems to be
a regression in gcc 4.6.3, which produces the warning;
however, gcc versions 4.4.7 and 4.7.2 do not.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In cases where the setting and access of a variable are
protected by the same conditional flag, older versions of
gcc would generate a "might be used unitialized" warning. We
silence the warning by initializing the variable to itself,
a hack that gcc recognizes.
Modern versions of gcc are smart enough to get this right,
going back to at least version 4.3.5. gcc 4.1 does get it
wrong in both cases, but is sufficiently old that we
probably don't need to care about it anymore.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is shorter, idiomatic, and it means the compiler does
not get confused about whether our "e" pointer is valid,
letting us drop the "e = e" hack.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
