git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Sep 2, 2011, 16:25 UTC
Message-ID
<20110902162524.GC19690@sigill.intra.peff.net>
In-Reply-To
<7v4o0uncq0.fsf@alter.siamese.dyndns.org>
On Fri, Sep 02, 2011 at 09:14:15AM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 27 in “Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?”
  1. Junio C HamanoSep 1, 2011
  2. Junio C HamanoSep 1, 2011
  3. Shawn PearceSep 1, 2011
  4. Michael J GruberSep 1, 2011
  5. Matthieu MoySep 1, 2011
  6. Shawn PearceSep 1, 2011
  7. Matthieu MoySep 2, 2011
  8. Jeff KingSep 2, 2011
  9. Johannes SixtSep 2, 2011
  10. Jeff KingSep 2, 2011
  11. Michael J GruberSep 2, 2011
  12. Jeff KingSep 2, 2011
  13. Junio C HamanoSep 2, 2011
  14. Jeff KingSep 2, 2011
  15. Junio C HamanoSep 2, 2011
  16. Shawn PearceSep 5, 2011
  17. Jeff KingSep 5, 2011
  18. Shawn PearceSep 5, 2011
  19. Jeff KingSep 5, 2011
  20. Shawn PearceSep 5, 2011
  21. fetch: bigger forced-update warningsJeff King, Sep 7, 2011
  22. Shawn PearceSep 7, 2011
  23. Junio C HamanoSep 7, 2011
  24. Jeff KingSep 7, 2011
  25. Thomas RastSep 7, 2011
  26. Matthieu MoySep 6, 2011
  27. Michael J GruberSep 6, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.