On Fri, Apr 21, 2017 at 1:42 PM, Michael Haggerty wrote:
> On 04/21/2017 08:32 AM, Michael Haggerty wrote:
>> [...]
>> I've CCed Duy because I don't know whether he has more plans regarding
>> submodule references [...] get rid of the
>> `for_each_ref_submodule()` family of functions entirely.
>>
On 04/21/2017 08:32 AM, Michael Haggerty wrote:
> [...]
> I've CCed Duy because I don't know whether he has more plans regarding
> submodule references [...] get rid of the
> `for_each_ref_submodule()` family of functions entirely.
>
> So perhaps the code that this patch touches won't be around lo
On 04/21/2017 03:12 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> + Junio
>
> Just like Michael, I do not have strong enough opinion for or
> against this patch to comment on it.
>
> I do agree with you that it would be a good longer-term direction to
> use "submodule" for a "struct su
Stefan Beller writes:
> + Junio
Just like Michael, I do not have strong enough opinion for or
against this patch to comment on it.
I do agree with you that it would be a good longer-term direction to
use "submodule" for a "struct submodule" (i.e. submodule object),
and call a string that names
+ Junio
On Wed, Apr 12, 2017 at 1:00 PM, Stefan Beller wrote:
> In submodule land we carefully need to distinguish between the path of a
> submodule and its name.
>
> The path of a submodule is the path that is recorded in the working tree
> of the superproject and describes where the submodule i
In submodule land we carefully need to distinguish between the path of a
submodule and its name.
The path of a submodule is the path that is recorded in the working tree
of the superproject and describes where the submodule is bound to the
superprojects tree.
The name as introduced in 941987a554
6 matches
Mail list logo
