On 2016-07-27 at 14:32 -0400, Jeff King wrote: > Yeah, I agree the "!" test for "did it work" is counter-intuitive if you're > coming from other languages, but it's pretty normal for C code bases > (especially ours). For stuff returning pointers, sure. > Ah. Yeah, those are wrong and bad. We should fix that. K, noted, will go back over this thread before I touch code and pick these all up. > I don't buy the tabs-become-spaces argument. We use tabs for indentation > in Git, and that's extremely unlikely to change. If your patch gets > munged in transit or by your editor, then the maintainer is going to > complain when applying your patch. Okay. (I happen to think that robustness against a cycle of developers discussing why whitespace broke patches in transit is good, but I'll change this). > The magic function you are looking for is "test_tick()", which advances Ah. Too tired last night, didn't realize that when I switched from constructing things on branches to have branch action in the reflog, to "just need commits really", to "previous tests did this" I lost the `test_tick()` invocation and for some reason when I looked at the results, decided I must be missing something about resolution instead of realizing that I was no longer calling `test_tick()`. Which leads to a final point: I'm not going to write any more code today, for reasons of "weak human needs sleep and I'll make more stupid mistakes if I continue". So I'm going silent on this thread for the rest of today. Not ignoring. If folks want fast progress (I haven't looked at release cycle status) I won't mind cutting me out of the loop :-D but otherwise I'll look Thu/Fri this week for any remedial work and offer a fresh patch with fixes from this thread, and documentation. I'm tempted to just steal the docs from Ted's patch, unless that's considered bad form? -Phil -- 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