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

Re: [PATCH] Clarify that '--tags' fetches tags only

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 22, 2011, 04:28 UTC
Message-ID
<7vfwjpyzds.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CAMOZ1BtPJ_Ddxo1UG2cxJMnGv9y8sR0rAyk3d_5JEz4kLsUQJQ@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
Show 17 quoted lines
> On Thu, Sep 22, 2011 at 03:13, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>>
>> Maybe:
>>
>> Note that if this option is specified, then only tags
>> are fetched. No other refs, such as a remote tracking
>> branch, will be updated, even if it has been updated
>> on the remote end.
>>
>> extra info on how this option is merely a short-hand for writing the
>> refspec `refs/tags/*:refs/tags/* could go here
>
> Junio just explained why your description is inadequate and confusing.
> ...
> If I were a newbie and were to read the text that I just proferred as
> a clarification of --tags, then I would next look up just WTF a
> refspec is, and then a branch, and then...

I do agree with you that it is a futile exercise to sweep fundamental concepts under the rug, fearing that they are too detailed and too hard for the casual readers. By understanding how simple the fundamental concepts and rules are, readers can have a coherent and clear mental model of the world and synthesize these fundamental rules to understand more complex operations the Porcelain commands offer to help every day tasks.

I however do not think, and I certainly did not mean, that the description of "--tags" option is necessarily the place we should bombard a new user with the term refspec and "refs/tags/*:refs/tags/*" syntax.

I expect the readers to, and I hope the documentation to help them to, understand the following three basic facts and rules before diving into descriptions of individual options, such as the paragraph we are discussing:

 * "git fetch" command serves two purposes:
   (1) It transfers objects the repository the command is invoked in does
   not have from the remote repository. The objects transferred are the
   commits that are necessary to complete the ancestry chain of _some_
   history, and data (i.e. trees and blobs) associated to use these
   commits.
   (2) It optionally can update the local refs (e.g. branches and tags)
   with copies of the refs taken from the remote repository.
 * In the above, the user needs to tell the command two things. One is
   "where the remote repository is". The other is "what refs to fetch and
   (optionally) how to store them". The latter "what to fetch" also
   determines what that "_some_ history" above is (i.e. everything
   reachable from the refs that are fetched).
 * "What to fetch and how to store" have a default, recorded in the
   repository configuration file, that is used when the user does not give
   that information to the command from the command line. If the user does
   give that information from the command line, that default is not used
   at all. IOW, the command line overrides the default.

With that understanding, the _only_ thing that "--tags" description needs to talk about is that it is an explicit way to give that "what to fetch and how to store" information from the command line. It instructs the command to fetch all the tags from the remote repository and store them locally.

If the logic flow of the document presents the list of options before helping the readers understand the above basic facts and rules, then I think _that_ is the problem with the document we need to be addressing, not the description of an individual option such as "--tags".

Previous: Michael WittenNext: Michael Witten
Message 12 of 32 in “Clarify that '--tags' fetches tags only”
  1. Clarify that '--tags' fetches tags onlyAnatol Pomozov, Sep 2, 2011
  2. Drew NorthupSep 2, 2011
  3. Clarify that '--tags' fetches tags onlyAnatol Pomozov, Sep 21, 2011
  4. Michael WittenSep 22, 2011
  5. Junio C HamanoSep 22, 2011
  6. Michael WittenSep 22, 2011
  7. Michael WittenSep 22, 2011
  8. Andrew ArdillSep 22, 2011
  9. Michael WittenSep 22, 2011
  10. Docs: Clarify the --tags option of `git fetch'Michael Witten, Sep 22, 2011
  11. Michael WittenSep 22, 2011
  12. Junio C HamanoSep 22, 2011
  13. Docs: Clarify the --tags option of `git fetch'Michael Witten, Sep 22, 2011
  14. Junio C HamanoSep 22, 2011
  15. Michael WittenSep 22, 2011
  16. Michael WittenSep 22, 2011
  17. Junio C HamanoSep 22, 2011
  18. Docs: Clarify the --tags option of `git fetch'Michael Witten, Sep 22, 2011
  19. Daniel JohnsonSep 22, 2011
  20. Peter ShenkinSep 30, 2011
  21. Jakub NarebskiSep 30, 2011
  22. Michael WittenSep 30, 2011
  23. Peter ShenkinOct 1, 2011
  24. Michael WittenOct 1, 2011
  25. Peter ShenkinOct 1, 2011
  26. Michael WittenOct 1, 2011
  27. Peter ShenkinOct 1, 2011
  28. Michael WittenOct 1, 2011
  29. Peter ShenkinOct 1, 2011
  30. Peter ShenkinOct 1, 2011
  31. Junio C HamanoSep 30, 2011
  32. Peter ShenkinOct 1, 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.