On Mon, Aug 23, 2021 at 09:47:28PM +0000, Marvin Häuser wrote: > > You'd want something like the patch below (and possibly something > > similar for the $subject handling). > > Thanks a lot! my last question for the patch would now be, how do I use your > snippet? Do I add you to S-o-b of the single patch, do I split the patches > with the second S-o-b being yours, or do I submit only the first and you > will submit the second? The usual thing is to just squash it into your patch. You can say something like "Test cases from Jeff King." in the commit message to give credit (though I am happy either way). And then ideally you'd have my sign-off to make it clear the code matches the DCO. So here it is (and you can just stick this before your sign-off at the end of the commit message): Signed-off-by: Jeff King <peff@xxxxxxxx> And then for the rest, you can follow the guide in Documentation/SubmittingPatches. Presumably you're comfortable using send-email, given the topic of the patch. :) But since you're got the patch on GitHub already, you can also use https://gitgitgadget.github.io. > > Both of the new tests fail without your patch and pass with it, but: > > > > - note the weird behavior I found with --in-reply-to; this is > > something we might want to address at the same time > > I think this case must error? The definition of the "--in-reply-to" does not > declare it as a default, so it must be enforced (and it is), but it's also > very unintuitive the file value is discarded. Who would decide the behaviour > spec? Given the text Carlo found in the documentation, I think this is the intended behavior. So I think we can make it part of the expected behavior in the test. I do still think that second test is worth having. An obvious-but-wrong thing to do here would be to set $in_reply_to to undef after the first iteration through the loop, rather than the value given on the command-line. The test makes sure we get that right. -Peff
