On Tue, May 3, 2016 at 4:37 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Pranit Bauva <pranit.bauva@xxxxxxxxx> writes: > >> Variable named 'verbose' in builtin/commit.c is consumed by git-status >> and git-commit so if a new verbose related behavior is introduced in >> git-commit, then it should not affect the behavior of git-status. >> >> One previous commit (title: commit: add a commit.verbose config >> variable) introduced a new config variable named commit.verbose, >> so care should be taken that it would not affect the behavior of >> status. >> >> Another previous commit (title: "parse-options.c: make OPTION_COUNTUP >> respect "unspecified" values") changes the initial value of verbose >> from 0 to -1. This can cause git-status to display a verbose output even >> when it isn't supposed to. >> >> Signed-off-by: Pranit Bauva <pranit.bauva@xxxxxxxxx> >> >> --- >> This is a split off from the previous patch 6/6 as suggested by Eric >> Sunshine. > > If these are documenting what your previous patches broke, then > there test body should describe what should happen, and then if it > is broken, use test_expect_failure, no? > > Your first test does "run status with commit.verbose is set, and > make sure the "diff --git" does not appear", which is correct, so if > it does not work, test_expect_failure would be the right thing to > use. > > These, especially the latter, look rather unpleasant regressions to > me, and the main commit.verbose change would need to be held back > before they are fixed. I agree that using test_expect_failure would be a better way of going with this thing. Thanks. Will send an updated patch for this. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html