git/ident.c, branch v2.9.2

Merge branch 'nd/error-errno'

2016-05-17T21:38:28Z

The code for warning_errno/die_errno has been refactored and a new error_errno() reporting helper is introduced. * nd/error-errno: (41 commits) wrapper.c: use warning_errno() vcs-svn: use error_errno() upload-pack.c: use error_errno() unpack-trees.c: use error_errno() transport-helper.c: use error_errno() sha1_file.c: use {error,die,warning}_errno() server-info.c: use error_errno() sequencer.c: use error_errno() run-command.c: use error_errno() rerere.c: use error_errno() and warning_errno() reachable.c: use error_errno() mailmap.c: use error_errno() ident.c: use warning_errno() http.c: use error_errno() and warning_errno() grep.c: use error_errno() gpg-interface.c: use error_errno() fast-import.c: use error_errno() entry.c: use error_errno() editor.c: use error_errno() diff-no-index.c: use error_errno() ...

ident.c: use warning_errno()

2016-05-09T19:29:08Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'da/user-useconfigonly'

2016-04-29T19:59:06Z

The "user.useConfigOnly" configuration variable makes it an error if users do not explicitly set user.name and user.email. However, its check was not done early enough and allowed another error to trigger, reporting that the default value we guessed from the system setting was unusable. This was a suboptimal end-user experience as we want the users to set user.name/user.email without relying on the auto-detection at all. * da/user-useconfigonly: ident: give "please tell me" message upon useConfigOnly error ident: check for useConfigOnly before auto-detection of name/email

ident: give "please tell me" message upon useConfigOnly error

2016-04-01T22:01:20Z

The env_hint message applies perfectly to the case when user.useConfigOnly is set and at least one of the user.name and the user.email are not provided. Additionally, use a less descriptive error message to discourage users from disabling user.useConfigOnly configuration variable to work around this error condition. We want to encourage them to set user.name or user.email instead. Signed-off-by: Marios Titas Signed-off-by: Junio C Hamano

ident: check for useConfigOnly before auto-detection of name/email

2016-04-01T21:57:55Z

If user.useConfigOnly is set, it does not make sense to try to auto-detect the name and/or the email. The auto-detection may even result in a bogus name and trigger an error message. Check if the use-config-only is set and die if no explicit name was given, before attempting to auto-detect, to correct this. Signed-off-by: Marios Titas Signed-off-by: Junio C Hamano

Merge branch 'da/user-useconfigonly'

2016-02-17T18:13:31Z

The "user.useConfigOnly" configuration variable can be used to force the user to always set user.email & user.name configuration variables, serving as a reminder for those who work on multiple projects and do not want to put these in their $HOME/.gitconfig. * da/user-useconfigonly: ident: add user.useConfigOnly boolean for when ident shouldn't be guessed fmt_ident: refactor strictness checks

ident: add user.useConfigOnly boolean for when ident shouldn't be guessed

2016-02-08T19:06:28Z

It used to be that: git config --global user.email "(none)" was a viable way for people to force themselves to set user.email in each repository. This was helpful for people with more than one email address, targeting different email addresses for different clones, as it barred git from creating a commit unless the user.email config was set in the per-repo config to the correct email address. A recent change, 19ce497c (ident: keep a flag for bogus default_email, 2015-12-10), however, declared that an explicitly configured user.email is not bogus, no matter what its value is, so this hack no longer works. Provide the same functionality by adding a new configuration variable user.useConfigOnly; when this variable is set, the user must explicitly set user.email configuration. Signed-off-by: Junio C Hamano Helped-by: Eric Sunshine Signed-off-by: Jeff King Signed-off-by: Dan Aloni Signed-off-by: Junio C Hamano

fmt_ident: refactor strictness checks

2016-02-04T21:18:48Z

This function has evolved quite a bit over time, and as a result, the logic for "is this an OK ident" has been sprinkled throughout. This ends up with a lot of redundant conditionals, like checking want_name repeatedly. Worse, we want to know in many cases whether we are using the "default" ident, and we do so by comparing directly to the global strbuf, which violates the abstraction of the ident_default_* functions. Let's reorganize the function into a hierarchy of conditionals to handle similar cases together. The only case that doesn't just work naturally for this is that of an empty name, where our advice is different based on whether we came from ident_default_name() or not. We can use a simple flag to cover this case. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ident.c: read /etc/mailname with strbuf_getline()

2016-01-15T18:34:41Z

Just in case /etc/mailname file was edited with a DOS editor, read it with strbuf_getline() so that a stray CR is not included as the last character of the mail hostname. We _might_ want to more aggressively discard whitespace characters around the line with strbuf_trim(), but that is a bit outside the scope of this series. Signed-off-by: Junio C Hamano

strbuf: introduce strbuf_getline_{lf,nul}()

2016-01-15T18:12:51Z

The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano