Hi Junio, On Tue, 14 Sep 2021, Junio C Hamano wrote: > An alternative would be to bypass the contrib/ phase and start as a > new subcommand that is first-class citizen from day one and let it > spend as much time as it needs to mature. I don't think that there is a lot of sense in that. The main benefits of `scalar` are in the `register` and the `clone` part, and the most natural end game would hence be for `git init` and `git clone` to sprout new options to support Scalar's features, in a Git-native way. As I have explained earlier, the `scalar` command has existing users, and therefore its command-line interface is not up for discussion (for example, turning `scalar` into `git scalar` would be a usability disaster). Scalar's _functionality_, however, should make it into Git proper. Into existing built-ins, that is. So I don't think that the contrib/ phase can be by-passed. It would not make sense to port Scalar to a new builtin. To the contrary, contrib/scalar/ should be the final destination for the `scalar` command. And you can't bypass a final destination. That simply makes no sense. So why bother with contrib/ at all? you may ask. The reason is that it makes it substantially easier for me to move the features into core Git, as I can incrementally implement those new options for Git's built-ins, use them in `contrib/scalar/` instead of duplicating the functionality, and then make use of Scalar's Functional Test suite for a much more comprehensive testing (which has served us already really well in the past). It also doesn't hurt that this way, my day job will be very happy because Scalar users directly benefit from that work. Of course, these suggestions to integrate Scalar more into the core part of Git (missing the point that the final destination for the functionality is not a new built-in, but rather new options for existing built-ins) made everything much more cumbersome for me instead, for no gain that would be apparent to me, impeding on aforementioned ease to move the features into core Git (which has not happened yet, as a consequence), but hopefully this will soon be a thing of the past. So I would like to request that we close the discussion about the question whether to integrate Scalar more into the top-level Makefile or into git.c, and instead go ahead with keeping the `scalar` command in contrib/scalar/. The freed-up time can then be used to focus on the much more rewarding project of upstreaming Scalar's functionality such as teaching `git clone` a short-and-sweet option that Just Makes Sense for large monorepos (i.e. that imitates at least a large part of what `scalar clone` does right now). Ciao, Dscho
