Re: [PATCH] clone tests: rename t57* => t56*

From: Stefan Beller <sbeller@google.com>
Date: Mar 15, 2016, 22:00 UTC
Message-ID: <CAGZ79kZWMhL5kTHU8gdPvm=VqDb58H0ZkNyop=c=P6bLLY1JLg@mail.gmail.com>
In-Reply-To: <20160315215121.GA30011@sigill.intra.peff.net>

On Tue, Mar 15, 2016 at 2:51 PM, Jeff King <peff@peff.net> wrote:

Show 51 quoted lines

> On Tue, Mar 15, 2016 at 02:25:50PM -0700, Stefan Beller wrote:
>
>> When trying to find a good spot for testing clone with submodules, I
>> got confused where to add a new test file. There are both tests in t560*
>> as well as t57* both testing the clone command. t/README claims the
>> second digit is to indicate the command, which is inconsistent to the
>> current naming structure.
>>
>> Rename all t57* tests to be in t56* to follow the pattern of the digits
>> as laid out in t/README.
>>
>> It would have been less work to rename t56* => t57* because there are less
>> files, but the tests in t56* look more basic and I assumed the higher the
>> last digits the more complicated niche details are tested, so with the patch
>> now it looks more in order to me.
>
> This seems like a good change to me. There definitely is a general sense
> of "more complex things should come later" in the test suite[1], so
> preserving the existing ordering seems reasonable.
>
>> If there is a reason to have 2 separate spaces for clone testing,
>> and I missed it, we should document that why it is important to keep
>> them separate.
>
> It looks like it was just carelessness from long ago. 5600 was added by
> 5508a616 (Feb 2006), and then t5700 in cf9dc653 (May 2006). For the
> later ones, everybody probably just found or the other and built on top
> (some of us even found both at various times; looks like I added t5708
> in 2011 and t5603 last year).
>
> I checked whether there were any stragglers in topics in flight with:
>
>   git log --oneline --name-status --diff-filter=A origin..origin/pu t
>
> but I think we are good.
>
> -Peff
>
> [1] I actually don't think the test ordering matters all that much. I
>     guess if you run the tests directly from the Makefile, it will stop
>     at the most basic test that fails.
>
>     Personally, I run them in longest-to-shortest via "prove", which
>     helps parallelism, and gives you the full list of failed tests.
>     Which is often a good piece of knowledge by itself (is it just one
>     test, or did I horribly break some fundamental part of git?). And
>     then I pick one of the failures to study based on what seems simple
>     to debug, and/or the area I've been making changes in.
>
>     But I dunno. Maybe other people really do care about the order. It
>     doesn't hurt to roughly follow the "simplest comes first" ordering.

Talking about ordering, I have two use cases

1) Before sending out patches: "git rebase -i -x make -x 'make test' <anchor>"
  to catch myself for doing stupid things.

2) When developing new code, I alternate between running an indivdual test
  "cd t && GIT_TRACE=1 ./t7400... -d -i -x -v " and running prove for all tests
  to have a good check if there are other niches I missed.

So I do not really have strong preference for the right order, I even thought about omitting the paragraph from the commit message and wanted to put it into the notes below, but then I figured I want to record it as I was frustrated about the commit messages from 2006 as they don't answer simple questions like "Why did you use a different second digit?", so I figured if anyone digs up my commit eventually I want to record as much of my current reasoning even if it is minor to help a future developer?