patch, 3 partsremote-helpers: fix the run of all tests

> On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > +export TEST_LINT :=
> 
> I think "test-lint-executable" still makes sense here.

> On Mon, Apr 01, 2013 at 11:46:00PM +0200, Antoine Pelisse wrote:
> 
>> On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> +export TEST_LINT :=
>>
>> I think "test-lint-executable" still makes sense here.
> 
> Also test-lint-shell-syntax, which finds a problem with the current
> code:
> 
>   $ cd contrib/remote-helpers
>   $ make test TEST_LINT=test-lint-shell-syntax
>   make -e -C ../../t test
>   make[1]: Entering directory `/home/peff/compile/git/t'
>   rm -f -r test-results
>   /home/peff/compile/git/contrib/remote-helpers/test-bzr.sh:139: error: echo -n is not portable (please use printf):   echo -n content > expected &&
>   make[1]: *** [test-lint-shell-syntax] Error 1
>   make[1]: Leaving directory `/home/peff/compile/git/t'
>   make: *** [test] Error 2
> 
> I think the check for duplicate-numbers is the only one that does not
> make sense. 

> > I think the check for duplicate-numbers is the only one that does not
> > make sense. 
> []
> Not sure about that, I send a suggestion of a patch in a minute.
> Highlights:
> 1) - rename the contrib test cases and assigns real TC numbers
> 2) - Forward the numbers into the main "test Makefile"

> On Tue, Apr 02, 2013 at 06:53:28PM +0200, Torsten Bögershausen wrote:
> 
>>> I think the check for duplicate-numbers is the only one that does not
>>> make sense. 
>> []
>> Not sure about that, I send a suggestion of a patch in a minute.
>> Highlights:
>> 1) - rename the contrib test cases and assigns real TC numbers
>> 2) - Forward the numbers into the main "test Makefile"
> 
> I'm not sure if this is a good idea or not. It puts the
> contrib/remote-helpers into the same "number namespace" as the rest of
> the test scripts, and enforces uniqueness with test-lint-duplicates,
> when "make test" is run from contrib/remote-helpers. But people working
> on the main test scripts would not get any such check, and would happily
> break contrib/remote-helpers by adding duplicate test numbers.
> 
> It makes sense to me to either:
> 
>   1. Have the contrib/remote-helpers test live in their own test
>      namespace completely, with their own numbers and test-results, and
>      pull in relevant bits from the main test harness. We do this
>      already with contrib/subtree.  I suggested this when the tests
>      first appeared, but there was some argument, and I don't remember
>      the details.
> 
>   2. Just integrate contrib test scripts into the main repository, but
>      leave them off by default. For example, add:
> 
>        if test -z "$GIT_TEST_REMOTE_HELPERS"; then
>               skip_all="Remote helper tests disabled (define GIT_TEST_REMOTE_HELPERS)"
>               test_done
>        fi
> 
>      to the top of the scripts, and then set GIT_TEST_REMOTE_HELPERS
>      in contrib/remote-helpers/Makefile before chaining to the test
>      Makefile.
> 
> -Peff

> On Tue, Apr 02, 2013 at 06:53:28PM +0200, Torsten Bögershausen wrote:
>
>> > I think the check for duplicate-numbers is the only one that does not
>> > make sense. 
>> []
>> Not sure about that, I send a suggestion of a patch in a minute.
>> Highlights:
>> 1) - rename the contrib test cases and assigns real TC numbers
>> 2) - Forward the numbers into the main "test Makefile"
>
> I'm not sure if this is a good idea or not.

> It puts the
> contrib/remote-helpers into the same "number namespace" as the rest of
> the test scripts, and enforces uniqueness with test-lint-duplicates,
> when "make test" is run from contrib/remote-helpers. But people working
> on the main test scripts would not get any such check, and would happily
> break contrib/remote-helpers by adding duplicate test numbers.
>
> It makes sense to me to either:
>
>   1. Have the contrib/remote-helpers test live in their own test
>      namespace completely, with their own numbers and test-results, and
>      pull in relevant bits from the main test harness. We do this
>      already with contrib/subtree.  I suggested this when the tests
>      first appeared, but there was some argument, and I don't remember
>      the details.

>   2. Just integrate contrib test scripts into the main repository, but
>      leave them off by default. For example, add:
>
>        if test -z "$GIT_TEST_REMOTE_HELPERS"; then
>               skip_all="Remote helper tests disabled (define GIT_TEST_REMOTE_HELPERS)"
>               test_done
>        fi
>
>      to the top of the scripts, and then set GIT_TEST_REMOTE_HELPERS
>      in contrib/remote-helpers/Makefile before chaining to the test
>      Makefile.

> On Mon, Apr 01, 2013 at 11:46:00PM +0200, Antoine Pelisse wrote:
> 
> > On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > > +export TEST_LINT :=
> > 
> > I think "test-lint-executable" still makes sense here.
> 
> Also test-lint-shell-syntax, which finds a problem with the current
> code:
> 
>   $ cd contrib/remote-helpers
>   $ make test TEST_LINT=test-lint-shell-syntax
>   make -e -C ../../t test
>   make[1]: Entering directory `/home/peff/compile/git/t'
>   rm -f -r test-results
>   /home/peff/compile/git/contrib/remote-helpers/test-bzr.sh:139: error: echo -n is not portable (please use printf):   echo -n content > expected &&
>   make[1]: *** [test-lint-shell-syntax] Error 1
>   make[1]: Leaving directory `/home/peff/compile/git/t'
>   make: *** [test] Error 2

>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  contrib/remote-helpers/test-bzr.sh | 14 --------------
>  1 file changed, 14 deletions(-)
>
> diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh
> index 70aa8a0..5dac171 100755
> --- a/contrib/remote-helpers/test-bzr.sh
> +++ b/contrib/remote-helpers/test-bzr.sh
> @@ -17,20 +17,6 @@ if ! "$PYTHON_PATH" -c 'import bzrlib'; then
>  	test_done
>  fi
>  
> -cmd='
> -import bzrlib
> -bzrlib.initialize()
> -import bzrlib.plugin
> -bzrlib.plugin.load_plugins()
> -import bzrlib.plugins.fastimport
> -'
> -
> -if ! "$PYTHON_PATH" -c "$cmd"; then
> -	echo "consider setting BZR_PLUGIN_PATH=$HOME/.bazaar/plugins" 1>&2
> -	skip_all='skipping remote-bzr tests; bzr-fastimport not available'
> -	test_done
> -fi
> -
>  check () {
>  	(cd $1 &&
>  	git log --format='%s' -1 &&

> I'm having an error in "contrib/remote-helpers/test-hg.sh" and it
> reproduces on every version I tested since you implemented it. Is it
> something in my environment that would make it wrong ?
>
> Cheers,
> Antoine
>
> ---
> expecting success:
>   test_when_finished "rm -rf gitrepo*" &&
>
>   (
>   cd hgrepo &&
>   hg update -r 0
>   ) &&
>
>   git clone "hg::$PWD/hgrepo" gitrepo &&
>   check gitrepo zero master
>
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> Cloning into 'gitrepo'...
> --- expected 2013-04-01 21:46:32.086796549 +0000
> +++ actual 2013-04-01 21:46:32.086796549 +0000
> @@ -1,2 +1,2 @@
> -zero
> -refs/heads/master
> +feature-a
> +refs/heads/feature-a
> not ok 4 - cloning with detached head