All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 4/5] Add --remote option to send-pack
Date: Wed, 02 May 2007 23:13:01 -0700	[thread overview]
Message-ID: <7vejly305u.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0705030137520.28708@iabervon.org> (Daniel Barkalow's message of "Thu, 3 May 2007 01:45:48 -0400 (EDT)")

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.

  reply	other threads:[~2007-05-03  6:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-28 17:05 [PATCH 4/5] Add --remote option to send-pack Daniel Barkalow
2007-04-29  5:49 ` Junio C Hamano
2007-04-29  6:01   ` Daniel Barkalow
2007-04-29  6:10     ` Shawn O. Pearce
2007-04-29  6:28     ` Junio C Hamano
2007-05-03  4:04       ` Daniel Barkalow
2007-05-03  5:35         ` Junio C Hamano
2007-05-03  5:45           ` Daniel Barkalow
2007-05-03  6:13             ` Junio C Hamano [this message]
2007-05-05  5:21               ` Daniel Barkalow
2007-05-05  6:33                 ` Junio C Hamano
2007-05-05  6:52                   ` Daniel Barkalow
2007-05-05  7:54                     ` Junio C Hamano
2007-05-05 17:56                       ` Daniel Barkalow
2007-05-07 20:08                       ` Loeliger Jon-LOELIGER

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vejly305u.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.