On Thu, May 19, 2016 at 11:55 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> I think this round is 99% there. The next step would be to answer
> "does the feature set we have here meet your needs that you wanted
> to fill with the submodule labels originally?" and I am hoping it is
> "yes".
But it's no. (...not quite / not yet)
I thought about this question since sending out the
series and I think we would want to improve submodules more.
In the original patch series "submodule groups" I tried to achieve two goals:
(A) a grouping scheme for submodules
(B) some sort of persistent configuration for such a group
(A) will be mostly solved now by the pathspec attrs. It may be a bit
confusing for users, as any other submodule related configuration is done
in .gitmodules. Also when moving a submodule (changing its path on the file
system, not the name in the config), any configuration still applies
except for the grouping scheme, which may not match any more.
(B) requires some thought though. Here is my vision:
1) Allow pathspecs for sparse checkout.
I wonder if we just add support for that in .git/info-sparse-checkout
or if we add a new file that is for pathspecs only, or we have a config
option whether sparse-checkout follows pathspecs or gitignore patterns
2) Teach `git clone` a new option `--sparse-checkout <pathspec>`
When that option is set the pathspec is written into the new file from
(1) and core.sparsecheckout is set to true
3) Advertise to do a `git clone --sparse-checkout
:(attr:default_submodules)`
Going this way we would help making submodules not different but integrate more
into other concepts of Git. As a downside this would require touching
sparse checkout which may be more time consuming than just adding a
`git clone --init-submodules-by-label` which stores the labels and only upddates
those submodules.
Or are there other ideas how to go from here?
Thanks,
Stefan
>
> Thanks.
--
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