Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

On Thu, Jul 28, 2016 at 9:22 AM, Junio C Hamano [off-list ref] wrote:

Stefan Beller [off-list ref] writes:

quoted

quoted

Anyway, I'll apply the "addition to the completion" patch.

Thanks.

Thanks for this patch!

Note: if we ever decide to resurrect sb/submodule-default-path,
we run into a merge conflict. The reasoning for using
"--recurse-submodules" instead of a plain "--recurse" makes sense
as well, so that merge conflict will be resolved in favor of this patch.

Thanks for an advance warning.  My rerere database has already been
taught about this conflict ;-)

As to sb/submodule-default-path topic, which has been blocked on
still-in-flux attribute work, I am tempted to declare that the
attribute work is not yet thread-ready but it is in a good enough
shape to base other works on, and have them advance to 'next'.

I am tempted to ask for delaying sb/submodule-default-path
a bit more and see if there is an alternative solution.

Inspired by Duys series on submodules and worktree I found a new
way how to do the submodule management (separation of the submodule
URL as a flag indicating the existence and the actual URL), and that
will be very similar to what is implemented in sb/submodule-default-path
just even more streamlined. (That said the state of that new series
is still vapor and not yet solid, so ... it's hopes and dreams.)

The traditional pattern of allowing the callers to randomly allocate
an array of "struct git_attr_check" and passing the pointer to its
first element to git_check_attr() function was impossible to extend
without having to update the callers, but we have migrated away from
the pattern and the attribute subsystem can be enhanced without
impacting the callers too much.