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

On Tue, Mar 15, 2016 at 2:51 PM, Jeff King [off-list ref] wrote:

On Tue, Mar 15, 2016 at 02:25:50PM -0700, Stefan Beller wrote:

quoted

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.

quoted

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?