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