On Fri, Sep 02, 2011 at 09:14:15AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > [1] My idea of "limited" would be an allow-known-good list of harmless > > config keys which we would respect when they came from the remote, with > > the option for the user to whitelist or blacklist more keys if they > > wanted. > > 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). But it becomes hard to keep your local config in sync with updates on the remote end. When the remote now adds "next" to the list of interesting branches, by what mechanism do you fix up your local config? Certainly we wouldn't want to rewrite the local config without consulting the user, because they may have reviewed or modified it since it was created. One possible solution is that the local config could dynamically depend on the remote config. E.g., the fetch refspec has something like a wildcard that matches only the branches that the remote provides to us via some "interesting branches" config key. Then it's OK for git to update the "interesting branches" key from the remote. Either the user is OK with respecting that (because they have left the wildcard in place), or not (because they have changed the refspec not to use that wildcard). I do worry that could quickly get complex, and people would start wanting a Turing-complete config language. :) -Peff -- 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