git/builtin/commit.c, branch v2.18.2

Merge branch 'bp/status-rename-config'

2018-05-30T05:04:07Z

"git status" learned to honor a new status.renames configuration to skip rename detection, which could be useful for those who want to do so without disabling the default rename detection done by the "git diff" command. * bp/status-rename-config: add status config and command line options for rename detection

Merge branch 'js/use-bug-macro'

2018-05-30T05:04:07Z

Developer support update, by using BUG() macro instead of die() to mark codepaths that should not happen more clearly. * js/use-bug-macro: BUG_exit_code: fix sparse "symbol not declared" warning Convert remaining die*(BUG) messages Replace all die("BUG: ...") calls by BUG() ones run-command: use BUG() to report bugs, not die() test-tool: help verifying BUG() code paths

add status config and command line options for rename detection

2018-05-13T01:57:37Z

After performing a merge that has conflicts git status will, by default, attempt to detect renames which causes many objects to be examined. In a virtualized repo, those objects do not exist locally so the rename logic triggers them to be fetched from the server. This results in the status call taking hours to complete on very large repos vs seconds with this patch. Add a new config status.renames setting to enable turning off rename detection during status and commit. This setting will default to the value of diff.renames. Add a new config status.renamelimit setting to to enable bounding the time spent finding out inexact renames during status and commit. This setting will default to the value of diff.renamelimit. Add --no-renames command line option to status that enables overriding the config setting from the command line. Add --find-renames[=] command line option to status that enables detecting renames and optionally setting the similarity index. Reviewed-by: Elijah Newren Original-Patch-by: Alejandro Pauly Signed-off-by: Ben Peart Signed-off-by: Junio C Hamano

Replace all die("BUG: ...") calls by BUG() ones

2018-05-06T10:06:13Z

In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro was introduced to use for reporting bugs instead of die(). It was then subsequently used to convert one single caller in 588a538ae55 (setup_git_env: convert die("BUG") to BUG(), 2017-05-12). The cover letter of the patch series containing this patch (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not terribly clear why only one call site was converted, or what the plan is for other, similar calls to die() to report bugs. Let's just convert all remaining ones in one fell swoop. This trick was performed by this invocation: sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c) Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

wt-status: use settings from git_diff_ui_config

2018-05-06T03:59:33Z

If you do something like - git add . - git status - git commit - git show (or git diff HEAD) one would expect to have analogous output from git status and git show (or similar diff-related programs). This is generally not the case, as git status has hard coded values for diff related options. With this commit the hard coded settings are dropped from the status command in favour for values provided by git_diff_ui_config. What follows are some remarks on the concrete options which were hard coded in git status: diffopt.detect_rename Since the very beginning of git status in a3e870f2e2 ("Add "commit" helper script", 2005-05-30), git status always used rename detection, whereas with commands like show and log one had to activate it with a command line option. After 5404c116aa ("diff: activate diff.renames by default", 2016-02-25) the default behaves the same by coincidence, but changing diff.renames to other values can break the consistency between git status and other commands again. With this commit one control the same default behaviour with diff.renames. diffopt.rename_limit Similarly one has the option diff.renamelimit to adjust this limit for all commands but git status. With this commit git status will also honor those. diffopt.break_opt Unlike the other two options this cannot be configured by a configuration option yet. This commit will also change the default behaviour to not use break rewrites. But as rename detection is most likely on, this is dangerous to be activated anyway as one can see here: https://public-inbox.org/git/xmqqegqaahnh.fsf@gitster.dls.corp.google.com/ Signed-off-by: Eckhard S. Maaß Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'bw/commit-partial-from-subdirectory-fix'

2018-04-25T04:28:53Z

"cd sub/dir && git commit ../path" ought to record the changes to the file "sub/path", but this regressed long time ago. * bw/commit-partial-from-subdirectory-fix: commit: allow partial commits with relative paths

commit: allow partial commits with relative paths

2018-04-05T08:05:48Z

Commit 8894d53580 (commit: allow partial commits with relative paths, 2011-07-30) ensured that partial commits were allowed when a user supplies a relative pathspec but then this was regressed in 5879f5684c (remove prefix argument from pathspec_prefix, 2011-09-04) when the prefix argument to 'pathspec_prefix' removed and the 'list_paths' function wasn't properly adjusted to cope with the change, resulting in over-eager pruning of the tree that is overlayed on the index. This fixes the regression and adds a regression test so this can be prevented in the future. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

Merge branch 'ma/skip-writing-unchanged-index'

2018-03-21T18:30:10Z

Internal API clean-up to allow write_locked_index() optionally skip writing the in-core index when it is not modified. * ma/skip-writing-unchanged-index: write_locked_index(): add flag to avoid writing unchanged index

Merge branch 'ab/gc-auto-in-commit'

2018-03-08T20:36:30Z

"git commit" used to run "gc --auto" near the end, which was lost when the command was reimplemented in C by mistake. * ab/gc-auto-in-commit: commit: run git gc --auto just before the post-commit hook

Merge branch 'jh/status-no-ahead-behind'

2018-03-08T20:36:24Z

"git status" can spend a lot of cycles to compute the relation between the current branch and its upstream, which can now be disabled with "--no-ahead-behind" option. * jh/status-no-ahead-behind: status: support --no-ahead-behind in long format status: update short status to respect --no-ahead-behind status: add --[no-]ahead-behind to status and commit for V2 format. stat_tracking_info: return +1 when branches not equal