From: Junio C Hamano <gitster@pobox.com>
To: Michael Witten <mfwitten@gmail.com>
Cc: Anatol Pomozov <anatol.pomozov@gmail.com>,
git@vger.kernel.org, computerdruid@gmail.com
Subject: Re: [PATCH] Clarify that '--tags' fetches tags only
Date: Wed, 21 Sep 2011 17:49:14 -0700 [thread overview]
Message-ID: <7vwrd1z9it.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAMOZ1BuSd52woX0utOQ84gbCzBkZg3ATKnE+7G_BrD5_hUQSiQ@mail.gmail.com> (Michael Witten's message of "Thu, 22 Sep 2011 00:13:21 +0000")
Michael Witten <mfwitten@gmail.com> writes:
> On Wed, Sep 21, 2011 at 23:52, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
>> + linkgit:git-config[1]. Note that if this option is specified
>> + then only tags are fetched, refs under refs/heads/* stay unchanged.
>
> Note that if this option is specified, then only tags
> are fetched; refs under refs/heads/* are not changed.
Can we improve the wording without singling out refs/heads/* specifically?
I think the updated wording is not desirable for two reasons.
For one thing, for the most newbies, I think refs/remotes/origin/* (not
refs/heads/*) would be the hierarchy that they may expect to get updated
and surprised.
When you give --tags (or any other refspec for that matter; --tags is
merely a short-hand for "refs/tags/*:refs/tags/*") explicitly from the
command line, you are overriding the refspecs configured for the remote,
and all the refs that are _not_ covered by the refspec you gave from the
command line will stay unchanged, not just refs/heads/* but refs under
other hierarchies (like refs/remotes/* and refs/notes/*).
Once the reader understands that the command line _overrides_ the
configured fetch refspecs, everything else should fall naturally into
place without further explanation. For example,
$ git pull origin frotz
would internally invoke "git fetch origin another_branch", and it would
not update any refs for the _same exact reason_ [*1*]. You are giving a
refspec from the command line (in this case, "grab refs/heads/frotz, but
do not store it anywhere"), and it overrides the usual fetch refspec that
may update "+refs/heads/*:refs/remotes/origin/*" (grab all refs at the
origin under refs/heads/ hierarchy, and store in refs/remotes/origin).
[Footnote]
*1* The merging of the result would update the current branch but that is
a natural consequence of "a pull integrates by running either a merge or a
rebase after running a fetch".
next prev parent reply other threads:[~2011-09-22 0:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-02 21:04 [PATCH] Clarify that '--tags' fetches tags only Anatol Pomozov
2011-09-02 21:18 ` Drew Northup
2011-09-21 23:52 ` Anatol Pomozov
2011-09-22 0:13 ` Michael Witten
2011-09-22 0:49 ` Junio C Hamano [this message]
2011-09-22 2:01 ` Michael Witten
2011-09-22 2:07 ` Michael Witten
2011-09-22 3:13 ` Andrew Ardill
2011-09-22 3:24 ` Michael Witten
2011-09-22 3:39 ` [PATCH] Docs: Clarify the --tags option of `git fetch' Michael Witten
2011-09-22 3:48 ` Michael Witten
2011-09-22 4:28 ` [PATCH] Clarify that '--tags' fetches tags only Junio C Hamano
2011-09-22 7:23 ` [PATCH v3] Docs: Clarify the --tags option of `git fetch' Michael Witten
2011-09-22 17:10 ` Junio C Hamano
2011-09-22 17:35 ` Michael Witten
2011-09-22 17:38 ` Michael Witten
2011-09-22 4:00 ` [PATCH] Clarify that '--tags' fetches tags only Junio C Hamano
2011-09-22 4:17 ` [PATCH v2] Docs: Clarify the --tags option of `git fetch' Michael Witten
2011-09-22 1:14 ` [PATCH] Clarify that '--tags' fetches tags only Daniel Johnson
2011-09-30 2:51 ` Peter Shenkin
2011-09-30 8:44 ` Jakub Narebski
2011-09-30 13:23 ` Michael Witten
2011-10-01 5:40 ` Peter Shenkin
2011-10-01 14:11 ` Michael Witten
2011-10-01 17:16 ` Peter Shenkin
2011-10-01 18:45 ` Michael Witten
2011-10-01 20:22 ` Peter Shenkin
2011-10-01 20:56 ` Michael Witten
2011-10-01 21:41 ` Peter Shenkin
2011-10-01 22:06 ` Peter Shenkin
2011-09-30 18:37 ` Junio C Hamano
2011-10-01 5:51 ` Peter Shenkin
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=7vwrd1z9it.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=anatol.pomozov@gmail.com \
--cc=computerdruid@gmail.com \
--cc=git@vger.kernel.org \
--cc=mfwitten@gmail.com \
/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.