git/builtin, branch v2.4.2

Merge branch 'jc/hash-object' into maint

2015-05-26T20:49:25Z

"hash-object --literally" introduced in v2.2 was not prepared to take a really long object type name. * jc/hash-object: write_sha1_file(): do not use a separate sha1[] array t1007: add hash-object --literally tests hash-object --literally: fix buffer overrun with extra-long object type git-hash-object.txt: document --literally option

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

hash-object --literally: fix buffer overrun with extra-long object type

2015-05-05T17:14:18Z

"hash-object" learned in 5ba9a93 (hash-object: add --literally option, 2014-09-11) to allow crafting a corrupt/broken object of unknown type. When the user-provided type is particularly long, however, it can overflow the relatively small stack-based character array handed to write_sha1_file_prepare() by hash_sha1_file() and write_sha1_file(), leading to stack corruption (and crash). Introduce a custom helper to allow arbitrarily long typenames just for "hash-object --literally". [jc: Eric's original used a strbuf in the more common codepaths, and I rewrote it to avoid penalizing the non-literally code. Bugs are mine] Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

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