git/builtin, branch v2.4.1

Merge branch 'jk/init-core-worktree-at-root' into maint

2015-05-13T21:05:49Z

We avoid setting core.worktree when the repository location is the ".git" directory directly at the top level of the working tree, but the code misdetected the case in which the working tree is at the root level of the filesystem (which arguably is a silly thing to do, but still valid). * jk/init-core-worktree-at-root: init: don't set core.worktree when initializing /.git

Sync with 2.3.8

2015-05-11T21:39:28Z

Signed-off-by: Junio C Hamano

Merge branch 'oh/fix-config-default-user-name-section' into maint-2.3

2015-05-11T21:33:59Z

The default $HOME/.gitconfig file created upon "git config --global" that edits it had incorrectly spelled user.name and user.email entries in it. * oh/fix-config-default-user-name-section: config: fix settings in default_user_config template

Merge branch 'ps/grep-help-all-callback-arg'

2015-04-20T22:28:34Z

Code clean-up. * ps/grep-help-all-callback-arg: grep: correctly initialize help-all option

config: fix settings in default_user_config template

2015-04-17T17:32:46Z

The name (not user) and email setting should be in config section "user" and not in "core" as documented in Documentation/config.txt. Signed-off-by: Ossi Herrala Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

Revert "merge: pass verbosity flag down to merge-recursive"

2015-04-16T15:03:14Z

This reverts commit 2bf15a3330a26183adc8563dbeeacc11294b8a01, whose intention was good, but the verbosity levels used in merge-recursive turns out to be rather uneven. For example, a merge of two branches with conflicting submodule updates used to report CONFLICT: output with --quiet but no longer (which *is* desired), while the final "Automatic merge failed; fix conflicts and then commit" message is still shown even with --quiet (which *is* inconsistent). Originally reported by Bryan Turner; it is too early to declare what the concensus is, but it seems that we would need to level the verbosity levels used in merge strategy backends before we can go forward. In the meantime, we'd revert to the old behaviour until that happens. cf. $gmane/267245

Merge branch 'jk/merge-quiet'

2015-04-14T18:49:12Z

"git merge --quiet" did not squelch messages from the underlying merge-recursive strategy. * jk/merge-quiet: merge: pass verbosity flag down to merge-recursive

Merge branch 'jc/update-instead-into-void'

2015-04-14T18:49:10Z

A push into an unborn branch, with "receive.denyCurrentBranch" set to "updateInstead", did not check out the working tree as expected. * jc/update-instead-into-void: push-to-deploy: allow pushing into an unborn branch and updating it

grep: correctly initialize help-all option

2015-04-13T05:46:28Z

The "help-all" option is being initialized with a wrong value. While being semantically wrong this can also cause a segmentation fault in gcc on ARMv7 hardfloat platforms with a hardened toolchain. Fix this by initializing with a NULL value. Signed-off-by: Patrick Steinhardt Reviewed-by: René Scharfe Signed-off-by: Junio C Hamano

merge: pass verbosity flag down to merge-recursive

2015-04-02T22:12:39Z

This makes "git merge --quiet" really quiet when we call into merge-recursive. Note that we can't just pass our flag down as-is; the two parts of the code use different scales. We center at "0" as normal for git-merge (with "--quiet" giving a negative value), but merge-recursive uses "2" as its center. This patch passes a negative value to merge-recursive rather than "1", though, as otherwise the user would have to use "-qqq" to squelch all messages (but the downside is that the user cannot distinguish between levels 0-2 if without resorting to the GIT_MERGE_VERBOSITY variable). We may want to review and renormalize the message severities in merge-recursive, but that does not have to happen now. This is at least in improvement in the sense that we are respecting "--quiet" at all. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano