On Thu, Dec 29, 2022 at 04:39:42AM -0800, Daniel Torrescusa Rubio wrote: (Rehashed the original text for easier commenting.)
[...] > I mean, for example. if there is some submodule on a git repository, the > default behaviour should be to make it available when you clone the > repository, and update it when is updated. > > Maybe there is a use case for not perform those actions, but in that case, > the submodule should be able to be configured (in the git repo config) and > behave as I descripted. > > I think that submodule functionality can be much more used if were more > transparent for the users. > > (Our use case is to maintain the .mvn folder in a single repository, with a > setup compatible for CI and local of all our repositories) To me, this looks like you first present some sort of generalization and then attempt to illustrate your point using a very narrow use-case. I surely may miss the point, but it's still something to keep in mind when pondering the design decisions: they must cater for different use-cases. > Were the requirements are described and can be discussed? You can try to discuss the design decisions with the deveopers on the main Git list. Be sure to read [1] which discusses how to do that. 1. https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20221229142417.a2wn24i6gif2f664%40carbon.
