Improve error messages when temporary file creation fails

Before, when creating a temporary file failed, a generic 'Unable to create
temporary file' message was printed. In some cases this could lead to
confusion as to which directory should be checked for correct permissions etc.

This patch adds the template for the temporary filename to the error message,
converting it to an absolute path if needed. A test verifies that the template
is indeed printed when pointing to a nonexistent or unwritable directory.

A copy of the original template is made in case mkstemp clears the template.

Signed-off-by: Arnout Engelen <arnouten@bzzt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
correct type of EMPTY_TREE_SHA1_BIN

Functions such as hashcmp that expect a binary SHA-1 value take
parameters of type "unsigned char *" to avoid accepting a textual
SHA-1 passed by mistake.  Unfortunately, this means passing the string
literal EMPTY_TREE_SHA1_BIN requires an ugly cast.  Tweak the
definition of EMPTY_TREE_SHA1_BIN to produce a value of more
convenient type.

In the future the definition might change to

	extern const unsigned char empty_tree_sha1_bin[20];
	#define EMPTY_TREE_SHA1_BIN empty_tree_sha1_bin

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
string_list_append: always set util pointer to NULL

It is not immediately obvious that the util field may
contain random bytes after appending an item. Especially
since the string_list_insert* functions _do_ explicitly zero
the util pointer.

This does not appear to be a bug in any current git code, as
all callers either fill in the util field immediately or
never use it. However, it is worth it to be less surprising
to new users of the string-list API who may expect it to be
intialized to NULL.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
configure: use AC_LANG_PROGRAM consistently

Avoid warnings from Autoconf 2.68 about missing use of AC_LANG_PROGRAM
and friends.

Quoting autoconf-2.68/NEWS:

  ** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
     AC_RUN_IFELSE now warn if the first argument failed to use
     AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file
     contents.  A new macro AC_LANG_DEFINES_PROVIDED exists if you have
     a compelling reason why you cannot use AC_LANG_SOURCE but must
     avoid the warning.

The underlying reason for that change is that AC_LANG_{SOURCE,PROGRAM}
take care to supply the previously computed set of #defines (and
include standard headers if so desired) for preprocessed languages
like C and C++.

In some cases, AC_LANG_PROGRAM is already used but not sufficiently
m4-quoted, so we just need to add another set of [quotes] to prevent
the autoconf warning from being triggered bogusly.  Quoting all
arguments (except when calling special macros that need to be expanded
before recursion) is better style, anyway.  These and more rules are
described in detail in 'info Autoconf "Programming in M4"'.

No change in the resulting config.mak.autogen after running
./configure intended.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
perl: command_bidi_pipe() method should set-up git environmens

When command_input_pipe and command_output_pipe are used as a
method of a Git::repository instance, they eventually call into
_cmd_exec method that sets up the execution environment such as
GIT_DIR, GIT_WORK_TREE environment variables and the current
working directory in the child process that interacts with the
repository.

command_bidi_pipe however didn't expect to be called as such, and
lacked all these set-up.  Because of this, a program that did this
did not work as expected:

    my $repo = Git->repository(Directory => '/some/where/else');
    my ($pid, $in, $out, $ctx) =
    $repo->command_bidi_pipe(qw(hash-object -w --stdin-paths));

This patch refactors the _cmd_exec into _setup_git_cmd_env that
sets up the execution environment, and makes _cmd_exec and
command_bidi_pipe to use it.

Note that unlike _cmd_exec that execv's a git command as an
external process, command_bidi_pipe is called from the main line
of control, and the execution environment needs to be restored
after open2() does its magic.

Signed-off-by: Masatake Osanai <unpush@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit,tag: use same wording for -F

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit,status: describe --porcelain just like push

Push has the clearer description, so take that one for all.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone,init: describe --template using the same wording

This also corrects a wrong description for clone.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit,merge,tag: describe -m likewise

This also removes the superfluous "specify" and rewords the misleading
"if any" which sounds as if omitting "-m" would omit the merge commit
message. (It means "if a merge commit is created at all".)

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add: describe --patch like checkout, reset

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit,status: describe -u likewise

They differ by one character only. Being exactly equal should help
translations.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-tag.txt: list all modes in the description

Currently, the description sounds as if it applied always, but most of
its content is true in "create tag mode" only.

Make this clearer by listing all modes upfront.

Also, sneak in some linguistic improvements and make it clearer that
lightweight tags are "created" because "written" may be misread as
"are output".

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pull: do not display fetch usage on --help-all

Currently, "git pull --help-all" displays the fetch usage info.

Make it equivalent to "git pull -h" instead since "--help-all" is
documented in gitcli(7).

Do not try to sanitize the pull option parser (aka last hair puller).

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: downcase placeholders in usage messages

We accumulated some inconsistencies without an explicit guidance to spell
this out over time.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make <identifier> lowercase as per CodingGuidelines

parse-options part

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make <identifier> lowercase as per CodingGuidelines

*.c part for matches with '"[A-Z]+"'.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make <identifier> lowercase as per CodingGuidelines

*.c part for matches with '<[A-Z]+>' (and affected test).

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: honor prepare-commit-msg hook

When a merge is stopped due to conflicts or --no-commit, the
subsequent commit calls the prepare-commit-msg hook. However,
it is not called after a clean merge. Fix this inconsistency
by invoking the hook after clean merges as well.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
parse_tag_buffer(): do not prefixcmp() out of range

There is a check (size < 64) at the beginning of the function, but
that only covers object+type lines.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push.default: Rename 'tracking' to 'upstream'

Users are sometimes confused with two different types of "tracking" behavior
in Git: "remote-tracking" branches (e.g. refs/remotes/*/*) versus the
merge/rebase relationship between a local branch and its @{upstream}
(controlled by branch.foo.remote and branch.foo.merge config settings).

When the push.default is set to 'tracking', it specifies that a branch should
be pushed to its @{upstream} branch. In other words, setting push.default to
'tracking' applies only to the latter of the above two types of "tracking"
behavior.

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

push.default == 'tracking' is left as a deprecated synonym for 'upstream'.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>