On Sun, Oct 18, 2020 at 06:32:19PM +0530, Shourya Shukla wrote: > 'git format-patch -v2 @~n', where 'n' is the number of commits which you > want to include in the patch. So in your case it will be: > 'git format-patch -v2 @~1' and a patch mail will be generated. (Note also that providing the name of the branch that yours is based off of is just as good, i.e., 'git format-patch -v2 master'). > Also, you need not put the '[Outreachy-Microproject]' tag in the > subject, '[OUTREACHY]' will suffice. Thanks for saying this. > Now, coming to the meat of the patch. > > > The test_path_is* functions provide debug-friendly upon failure. > > This commit can be redone to be even more better. This does not exactly > reflect what has been done. I understand that yes 'test_patch_is_*' > functions are better and why they are better. But where did you replace > them, this is left unanswered. > > This is one example of how the commit messages can be, not too verbose > and not too short, somewhere in the middle: > https://lore.kernel.org/git/20200118083326.9643-6-shouryashukla.oo@xxxxxxxxx/ I'm actually perfectly happy with the patch text; let's not overcomplicate something as straightforward as using a built-in test helper instead of 'test -f'. > The change is fine but I feel you can easily find files in which you can > do the same type of change but in a large quantity. This way you will > get an even better idea of how the tests work at Git. To find such > files, one way can be to look here: > https://github.com/git/git/tree/master/t I'm also fine with Caleb just working on t0000; sending this patch on its own would usually look like unnecessary churn unless it was either (a) preparation for some other modification to t0000, and we want to start from a modern-looking base, or (b) it is in the name of removing 'test -f' from 't' en-masse, in which case I'd expect this to cover all of our tests. Since this is just to get Caleb's feet wet, I'm fine with them starting small :). Sending this patch to the mailing list in a good format with a well-written commit message is exercise enough. > Here if you try finding files which had commits over 11-12+ years ago, > you will find some ancient relics to modernise too! Great that you took > Taylor's advice ;) :-) Thanks, Taylor
