On Thu, Apr 08 2021, Sergey Organov wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> On Thu, Apr 08 2021, Sergey Organov wrote: >> >>> There were 3 completion tests failures due to introduction of >>> log.diffMerges configuration variable that affected the result of >>> completion of log.d. Fixed them accordingly. >>> >>> Signed-off-by: Sergey Organov <sorganov@xxxxxxxxx> >>> --- >>> t/t9902-completion.sh | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh >>> index 04ce884ef5ac..4d732d6d4f81 100755 >>> --- a/t/t9902-completion.sh >>> +++ b/t/t9902-completion.sh >>> @@ -2306,6 +2306,7 @@ test_expect_success 'git config - variable name' ' >>> test_completion "git config log.d" <<-\EOF >>> log.date Z >>> log.decorate Z >>> + log.diffMerges Z >>> EOF >>> ' >>> >>> @@ -2327,6 +2328,7 @@ test_expect_success 'git -c - variable name' ' >>> test_completion "git -c log.d" <<-\EOF >>> log.date=Z >>> log.decorate=Z >>> + log.diffMerges=Z >>> EOF >>> ' >>> >>> @@ -2348,6 +2350,7 @@ test_expect_success 'git clone --config= - variable name' ' >>> test_completion "git clone --config=log.d" <<-\EOF >>> log.date=Z >>> log.decorate=Z >>> + log.diffMerges=Z >>> EOF >>> ' >> >> Commits should be made in such a way as to not break the build/tests >> partway through a series, which it seems is happening until this >> fixup. > > Yep. > > Could these tests be somehow written in a more robust manner, to be > protected against future additions of configuration variables that are > unrelated to the features being tested? If so, I'd prefer to fix them as > a prerequisite to the series rather than adding fixes to unrelated > existing tests into my patches. Hrm? I mean if you have a commit fixing up failing tests in an earlier commit then that change should in one way or the other be made as part of that earlier change. Yes we can skip the tests or something in the meantime, which we do sometimes as part of some really large changes, but these can just be squashed, no? >> Having read this far most of what you have in this 9 patch series >> could/should be squashed into something much smaller, e.g. tests being >> added for code added in previous steps, let's add the tests along with >> the code since this isn't such a large change. > > In general, I try to make commits as small as possible, but if you > prefer tests to be included with the code in the same commit, – that's > fine with me too. > > Will meld new tests into code commits for the next re-roll. I'm probably the last person to give advice on this list about not overly splitting up ones commits :) Having said that, some sage advice: It's really helpful to split commits into discrete understandable pieces when it aids in reviewing/understanding the code. But something like say your 8/9 is IMNSHO a step to far, you're just adding a feature earlier and then docs for it later. That doesn't help to review or understand the change, now you just need to look in two places for what's one logical change. Ditto for e.g. the 5/9 here. That's just a test for a feature added earlier. So let's add it to the commit where we add that feature. There *are* cases where it helps to split up these changes, but they're things like adding tests for existing behavior before changing something, as an aid to demonstrate what the behavior was before & after. In those cases it's a lot better to split the commits, because nobody wants to waste time discerning what's a test for existing v.s. new behavior.
