On Fri, Aug 5, 2016 at 2:06 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Stefan Beller <sbel...@google.com> writes:
>>> -               ${reference:+--reference "$reference"} \
>>> +               ${reference:+"$reference"} \
>> Note how this changed the API of the submodule--helper.
>> Currently we pass in --reference $reference
>> and $reference consists of the string "--reference" and the actual
>> reference. So it looked like '--reference' '--reference=foo'
> So this change is a strict bugfix.  The code without this patch
> had cmd_update that places "--reference=foo" in $reference, but
> the call to "git submodule--helper" it makes added an unnecessary
> "--reference" in front of it.

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.

It is more a cleanup of the internal communication between the shell
script and the helper written in C. (And that communication is
supposed to not be user visible or relevant)

> I was wondering why there is no corresponding change to add
> "--reference" on the code that calls cmd_update().  Thanks for
> saving my time ;-)

When I wrote the patch I cared more about the while-at-it part than
the bug fix as I do not consider the bug worth to merge down to maint
or even fast tracking it as a bug fix. It's just changing the internal
communication to be clearer.

> Perhaps that needs to go into the log message, though.  Allowing
> multiple references is not that interesting from the POV of the
> codebase immediately after this step and only deserves a "by the
> way" mention.
>     Subject: submodule--helper: fix cmd_update()
>     cmd_update places "--reference=foo" in $reference, but the call to
>     "git submodule--helper" it makes adds an unnecessary "--reference"
>     in front of it.  The underlying "git clone" was called with two
>     command options "--reference" and "--reference=foo" because of
>     this.
>     While at it, prepare the code to accept multiple references, as
>     the underlying "git clone" can happily take more than one.
> or something like that.
> Needless to say, "While at it" could become a separate step, and a
> pure bugfix part may even want to become a separate and more urgent
> topic that can go to 'maint', with a test to prevent regression.

Sure. I'll do so in a reroll.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to