Jeff King <peff@xxxxxxxx> writes: >> It coincides with my idea too, but it might be a very limited set. For >> example, there may be a good "suggested by upstream" default for LHS of >> fetch refspecs (e.g. somebody may have 47 topics published but majority of >> people are expected to follow only his "master" branch), but it is up to >> the user of that suggestion what the RHS would be. > > Yeah. That leads to synthesizing local keys based on what remote keys > say. Which is pretty straightforward if you are just fetching the > remote's config during clone, and then copying or creating local keys > based on that in your own .git/config (e.g., by creating full refspecs > with upstream's idea of the LHS, and our idea of the RHS). > ... > I do worry that could quickly get complex, and people would start > wanting a Turing-complete config language. :) My real point was that more often than not the settings of configuration variables are inherently per repository not per project, and even though we may hear people want shared configs, possibly in-tree, distributed as part of the projects, such a set-up would not be very useful, before you even consider merging updates but just taking them as suggested initial values. The choice to take, ignore, or tweak the suggestions all depend on the semantics of each variable, and it becomes more so once you start talking about merging updates. -- 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