On Tue, Mar 15, 2016 at 2:51 PM, Jeff King <peff@xxxxxxxx> wrote: > 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? -- 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