Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?

[Jeff King <peff@peff.net>]

On Fri, Sep 02, 2011 at 09:14:15AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> 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