I'm nearing completion on the patch for the --progress and --no-progress command-line options. I am able to manually validate the behavior, but am a bit stumped as to how to efficiently code up the test script. My manual test involves doing a git clone of the git repository, which produces the volume of I/O sufficiently bulky to trigger the progress message code. But that bulk means that the test case will take a long time to complete, hence making using a git clone of the git code in the test case impractical. Also, in order for the script to do its job, it will need to tell the difference between a git run that has progress from one that does not. The first idea would be to simply use shell command redirection on the git command itself, but that defeats the tty detection logic, so I don't think that is an option either. Does anyone have any recommendations here? If not, then I guess I will have to forgo the test script and just submit the patch without it. Thanks, Brent On Sun, Jan 25, 2009 at 1:19 AM, Boyd Stephen Smith Jr. <bss@xxxxxxxxxxxxxxxxx> wrote: > > On Saturday 24 January 2009, Brent Goodrick <bgoodr@xxxxxxxxx> wrote > about 'Re: CR codes from git commands': > >While I'm at it, what is the standard procedure for submitting git > >patches for review once I've cooked up and validated it on my end? I'm > >guessing posting the patch into this mailing list is part of the > >answer to that question. > > If you've got a patch, I assume you've got a checkout. Look in > Documentation/SubmittingPatches. > -- > Boyd Stephen Smith Jr. ,= ,-_-. =. > bss@xxxxxxxxxxxxxxxxx ((_/)o o(\_)) > ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' > http://iguanasuicide.net/ \_/ -- 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
