On Fri, Aug 5, 2016 at 2:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html