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

Re: [PATCH 4/5] Add --remote option to send-pack

From
Daniel Barkalow <barkalow@iabervon.org>
Date
May 5, 2007, 05:21 UTC
Message-ID
<Pine.LNX.4.64.0705050115270.28708@iabervon.org>
In-Reply-To
<7vejly305u.fsf@assigned-by-dhcp.cox.net>
On Wed, 2 May 2007, Junio C Hamano wrote:
Show 38 quoted lines
> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Indeed. Is there documentation on all the possibilities for refspecs 
> > somewhere all together? I could only find it for particular programs, and 
> > didn't see a no-colon option permitted anywhere.
> 
> Documentation/pull-fetch-param.txt which is included by various
> manpages would be the best place to start.
> 
>     <refspec>::
>             The canonical format of a <refspec> parameter is
>             `+?<src>:<dst>`; that is, an optional plus `+`, followed
>             by the source ref, followed by a colon `:`, followed by
>             the destination ref.
>     +
>     The remote ref that matches <src>
>     is fetched, and if <dst> is not empty string, the local
>     ref that matches it is fast forwarded using <src>.
>     Again, if the optional plus `+` is used, the local ref
>     is updated even if it does not result in a fast forward
>     update.
> 
> Hmph.  So <dst> could be empty, and in such a case there is no
> tracking.  But this does not say missing colon is allowed (but
> that was intentionally left out as we clarify it later).  Let's
> read on.  After a few [Notes], we find this.
> 
>     Some short-cut notations are also supported.
>     +
>     * `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; 
>       it requests fetching everything up to the given tag.
>     * A parameter <ref> without a colon is equivalent to
>       <ref>: when pulling/fetching, so it merges <ref> into the current
>       branch without storing the remote branch anywhere locally
> 
> Ahh, so a refspec that does not have a colon, and ends with a
> colon (hence an empty <dst>) are equivalent, and does not result
> in remote tracking.

Is this actually supported in config files? At least for pulls, the "tag <tag>" notation is only available on the command line, afaict. For that matter, I think that having "<ref>:" or "<ref>" in a config file fetch line would be really bad; these refs would always be merged into any current head (without any remote tracking) when the remote is fetched from?

	-Daniel
*This .sig left intentionally blank*
Previous: Junio C HamanoNext: Junio C Hamano
Message 10 of 15 in “Add --remote option to send-pack”
  1. 4/5 Add --remote option to send-packDaniel Barkalow, Apr 28, 2007
  2. Junio C HamanoApr 29, 2007
  3. Daniel BarkalowApr 29, 2007
  4. Shawn O. PearceApr 29, 2007
  5. Junio C HamanoApr 29, 2007
  6. Daniel BarkalowMay 3, 2007
  7. Junio C HamanoMay 3, 2007
  8. Daniel BarkalowMay 3, 2007
  9. Junio C HamanoMay 3, 2007
  10. Daniel BarkalowMay 5, 2007
  11. Junio C HamanoMay 5, 2007
  12. Daniel BarkalowMay 5, 2007
  13. Junio C HamanoMay 5, 2007
  14. Daniel BarkalowMay 5, 2007
  15. Loeliger Jon-LOELIGERMay 7, 2007

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.