summaryrefslogtreecommitdiff
path: root/builtin
diff options
context:
space:
mode:
authorElijah Newren <newren@gmail.com>2018-09-27 17:36:57 (GMT)
committerJunio C Hamano <gitster@pobox.com>2018-09-27 22:22:34 (GMT)
commit3e73cc62c0d80fedd1fc612e256b5eb3f3068de4 (patch)
tree662715cd0e27f7f17af2e5a0e5e8a05d15f123b0 /builtin
parent1d4361b0f344188ab5eec6dcea01f61a3a3a1670 (diff)
downloadgit-3e73cc62c0d80fedd1fc612e256b5eb3f3068de4.zip
git-3e73cc62c0d80fedd1fc612e256b5eb3f3068de4.tar.gz
git-3e73cc62c0d80fedd1fc612e256b5eb3f3068de4.tar.bz2
commit: fix erroneous BUG, 'multiple renames on the same target? how?'
builtin/commit.c:prepare_to_commit() can call run_status() twice if using the editor, including status, and the user attempts to record a non-merge empty commit without explicit --allow-empty. If there is also a rename involved as well (due to using 'git add -N'), then a BUG in wt-status.c is triggered: BUG: wt-status.c:476: multiple renames on the same target? how? The reason we hit this bug is that both run_status() calls use the same struct wt_status * (named s), and s->change is not freed between runs. Changes are inserted into s with string_list_insert, which usually means that the second run just recomputes all the same results and overwrites what was computed the first time. However, ever since commit 176ea7479309 ("wt-status.c: handle worktree renames", 2017-12-27), wt-status started checking for renames and copies but also added a preventative check that d->rename_status wasn't already set and output a BUG message if it was. The problem isn't that there are multiple rename targets to a single path as the error implies, the problem is that 's' is not freed/cleared between the two run_status() calls. Ever since commit dc6b1d92ca9c ("wt-status: use settings from git_diff_ui_config", 2018-05-04), which stopped hardcoding DIFF_DETECT_RENAME and allowed users to ask for copy detection, this bug has also been triggerable with a copy instead of a rename. Fix the bug by clearing s->change. A better change might be to clean up all of s between the two run_status() calls. A good first step towards such a goal might be writing a function to free the necessary fields in the wt_status * struct; a cursory glance at the code suggests all of its allocated data is probably leaked. However, doing all that cleanup is a bigger task for someone else interested to tackle; just fix the bug for now. Reported-by: Andrea Stacchiotti <andreastacchiotti@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin')
-rw-r--r--builtin/commit.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/builtin/commit.c b/builtin/commit.c
index 0d9828e..83233ca 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -872,6 +872,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
s->use_color = 0;
commitable = run_status(s->fp, index_file, prefix, 1, s);
s->use_color = saved_color_setting;
+ string_list_clear(&s->change, 1);
} else {
struct object_id oid;
const char *parent = "HEAD";