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

Re: [PATCH] Remove restriction on notes ref base

From
Jeff King <peff@peff.net>
Date
Nov 5, 2010, 14:55 UTC
Message-ID
<20101105145510.GA19087@sigill.intra.peff.net>
In-Reply-To
<201011050229.15941.johan@herland.net>
On Fri, Nov 05, 2010 at 02:29:15AM +0100, Johan Herland wrote:
> Actually, I don't have anything against auto-follow per se, and we could 
> easily enough extend the refspec to specify auto-follow behaviour: There is 

Yup, agreed. That would be sufficient to capture the current behavior (and IMHO makes it much more transparent to the user).

Show 10 quoted lines
> > This codifies that refs for remote $foo are in refs/remotes/$foo, which
> > is something we have avoided so far. For example, when finding the
> > "upstream" branch, we have the name of the remote and the merge branch,
> > look up the fetch refspecs in the config, and then figure out where that
> > branch would be fetched to. Which of course turns out as you say (as
> > remotes/$remote_name/$branch) in the default config, but we don't
> > restrict people to that.
> 
> We can do the same for "foo/bar" as well, although things become slightly 
> more fiddly:

Yeah, I don't think the problem is unsurmountable. But I do think it is worth doing the more complex behavior, as it keeps things "right" with respect to arbitrary config.

Show 13 quoted lines
> When "foo" exists as a remote, look up its fetch refspec(s), and determine 
> possible mappings for name "bar". I.e. given the following (non-default) 
> refspecs for remote "foo":
> 
>   +refs/heads/*:refs/remotes/spam/heads/*
>   +refs/tags/*:refs/remotes/eggs/tags/*
>   +refs/notes/*:refs/remotes/bacon/notes/*
> 
> we know that the intersection between the left side of these refspec and the 
> ref disambiguation rules consists of "refs/tags/bar" and "refs/heads/bar" 
> (in that order). We can then map these to the right side of the refspec to 
> get "refs/remotes/eggs/tags/bar" and "refs/remotes/spam/heads/bar" (in that 
> order). We would then use the first match from these alternatives.

Yeah, that makes sense. If the remote side is storing tags somewhere besides "refs/tags" you wouldn't find them, but that is probably a good thing.

-Peff
Previous: Johan HerlandNext: Jonathan Nieder
Message 20 of 21 in “Remove restriction on notes ref base”
  1. Remove restriction on notes ref baseKenny Root, Nov 2, 2010
  2. Jonathan NiederNov 2, 2010
  3. Johan HerlandNov 2, 2010
  4. Shawn PearceNov 2, 2010
  5. Jeff KingNov 2, 2010
  6. Johan HerlandNov 2, 2010
  7. Junio C HamanoNov 2, 2010
  8. Johan HerlandNov 2, 2010
  9. Chris ForbesNov 2, 2010
  10. Jonathan NiederNov 3, 2010
  11. Junio C HamanoNov 3, 2010
  12. Sverre RabbelierNov 3, 2010
  13. Johan HerlandNov 4, 2010
  14. Sverre RabbelierNov 4, 2010
  15. Tag refspecs (was Re: [PATCH] Remove restriction on notes ref base)Marc Branchaud, Nov 4, 2010
  16. Johan HerlandNov 5, 2010
  17. Marc BranchaudNov 5, 2010
  18. Jeff KingNov 4, 2010
  19. Johan HerlandNov 5, 2010
  20. Jeff KingNov 5, 2010
  21. Jonathan NiederNov 3, 2010

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.