Re: [PATCH 4/6] submodule--helper update-clone: allow multiple references

Stefan Beller [off-list ref] writes:

I thought about rolling it as a strict bugfix; but the bug is shaded by the
inverse bug in the helper, so the user would never see an issue.

Ahh, OK, because the helper accepts "--reference" "--reference=foo"
as a OPT_STRING whose value happens to be "--reference=foo", and
then uses

	if (suc->reference)
        	argv_array_push(&child->args, suc->reference)

where suc->reference _is_ "--reference=foo" when invoking the
underlying "git clone", it cancels out.

Then it is OK.

In fact there is NO bug.  It just is that update_clone subcommand
used a convention different from others that took the whole
--option=arg as a parameter to --reference option.  It could be
argued that it is an API bug between git-submodule.sh and
git-submodule--helper, but nobody else goes through this "weird"
interface, so it is not worth splitting the patch.

On Fri, Aug 5, 2016 at 2:31 PM, Junio C Hamano [off-list ref] wrote:

Stefan Beller [off-list ref] writes:

quoted

I thought about rolling it as a strict bugfix; but the bug is shaded by the
inverse bug in the helper, so the user would never see an issue.

Ahh, OK, because the helper accepts "--reference" "--reference=foo"
as a OPT_STRING whose value happens to be "--reference=foo", and
then uses

        if (suc->reference)
                argv_array_push(&child->args, suc->reference)

where suc->reference _is_ "--reference=foo" when invoking the
underlying "git clone", it cancels out.

Then it is OK.

In fact there is NO bug.  It just is that update_clone subcommand
used a convention different from others that took the whole
--option=arg as a parameter to --reference option.  It could be
argued that it is an API bug between git-submodule.sh and
git-submodule--helper, but nobody else goes through this "weird"
interface, so it is not worth splitting the patch.

I'll mention the fix of the API bug in the reroll then.