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

Re: [PATCH] Add examples section to 'git fetch' manual

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 13, 2008, 18:56 UTC
Message-ID
<7v63uld1nu.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20080413093424.GA12861@mithlond.arda.local>
Teemu Likonen <tlikonen@iki.fi> writes:
Show 6 quoted lines
> +EXAMPLES
> +--------
> +
> +git fetch git://host.xz/repo.git/ master:pu::
> +	Fetch branch `master` from given repository URL and store it locally
> +	as `pu`.

While this may technically be correct (and I'll say upfront that all of your "examples" may technically be correct), I would suggest strongly against putting this into EXAMPLES section. People look at examples section to look up something they need to do often; the section should describe the best practices we can suggest them in real life.

The above command line is a _great_ way to explain what happens under the hood when you have the matching configuration in .git/config for the remote, so that people would know how to update .git/config entries from what git-clone and "git-remote add" give them by default to suit their needs (e.g. instead of storing all branches in remotes/origin/*, you can configure to only fetch and store a few selected branches). But, fetching from somewhere and storing it explicitly _from the command line_ like your example command line is something you would _never_ do in real life if you know git.

> +git fetch git://host.xz/repo.git/ master:remotes/pu::
> +	Fetch branch `master` from given repository URL and store it locally as
> +	remote tracking branch `pu`.

And this example is even worse, as the common example is to have remote name between "remotes" and "pu".

> +git fetch git://host.xz/repo.git/ master::
> +	Fetch branch `master` from given repository URL but do not create the
> +	branch locally. Only the temporary pointer FETCH_HEAD is set to refer
> +	to the fetched branch.

This one is a fine example of a one-shot command to look at what they have without actually affecting your own history. Use of this form in real life is very sane.

> +git fetch alice master:remotes/alice/pu::
> +	Fetch branch `master` from remote named `alice` and store it locally as
> +	remote tracking branch `alice/pu`. See linkgit:git-remote[1] for more
> +	information on configuring remotes.

This is a wrong example on multiple counts (this is one of the worst one in your change, so I'll explain in more detail than for others).

First of all, think about the reason _why_ the convention is to use a separate namespace under remotes/ per remote. It is to allow us to use the names that correspond to what the remote repository uses without having to worry about name collisions, and the reason we took pains to implement the mechanism to allow you to use such corresponding names is to avoid having to remember "what she calls master is what I call pu".

"I want to make sure I can tell my master and her master apart without confusing myself, so I'd call mine master and call hers alice/master" is the recommended use pattern which "git clone" and "git remote add" give the user. An EXAMPLE that deviates from it without explaining why/when it is a good thing to do is BAD. Remember, many people blindly copy and paste the examples section without thinking, assuming that they suggest the best practice.

If you have nickname "alice" defined, you are by definition interacting with her regularly. If you are doing a one-off with such a repository, running "git fetch alice master" and operating on the resulting FETCH_HEAD (and you typically use tag or local branch if you want to mark that commit, with "git tag" or "git branch"), would be much less error prone, less confusing, and more straightforward recommended approach. Typically, you would have the usual refs/heads/*:refs/remotes/alice/* fetch refspec, so you would not even say "master" and instead run "git fetch alice" and look at "remotes/alice/master".

Your above command line again may be a great way to explain what you could do and what the mechanism is equipped to allow you to, but I do not think there is any reason to use it in the real life. It should not be in the EXAMPLE section.

Show 5 quoted lines
> +git fetch origin::
> +	From the remote named `origin` fetch and store all branches as
> +	configured in `remote.origin.fetch`. Usually this means fetching all
> +	branches and storing them locally as remote tracking branches
> +	`origin/*`. See linkgit:git-remote[1] for more information.

This is a valid thing to add to the examples section, although I suspect people would already know it when they encouter this page.

Previous: Teemu LikonenNext: Matt Graham
Message 24 of 86 in “git annoyances”
  1. Ingo MolnarApr 9, 2008
  2. Björn SteinbrinkApr 9, 2008
  3. Jeff KingApr 9, 2008
  4. git-remote: show all remotes with "git remote show"Jeff King, Apr 9, 2008
  5. Johannes SchindelinApr 9, 2008
  6. Junio C HamanoApr 10, 2008
  7. Ingo MolnarApr 9, 2008
  8. Ingo MolnarApr 10, 2008
  9. Avery PennarunApr 9, 2008
  10. Karl HasselströmApr 10, 2008
  11. Avery PennarunApr 10, 2008
  12. Karl HasselströmApr 11, 2008
  13. Friendly refspecs (Was: Re: git annoyances)Teemu Likonen, Apr 9, 2008
  14. Avery PennarunApr 9, 2008
  15. Jeff KingApr 9, 2008
  16. Teemu LikonenApr 9, 2008
  17. Jeff KingApr 9, 2008
  18. Jeff KingApr 10, 2008
  19. Jeff KingApr 10, 2008
  20. Junio C HamanoApr 10, 2008
  21. Jeff KingApr 10, 2008
  22. Teemu LikonenApr 13, 2008
  23. Add examples section to 'git fetch' manualTeemu Likonen, Apr 13, 2008
  24. Junio C HamanoApr 13, 2008
  25. Matt GrahamApr 13, 2008
  26. Teemu LikonenApr 13, 2008
  27. Junio C HamanoApr 14, 2008
  28. Jeff KingApr 16, 2008
  29. Jeff KingApr 16, 2008
  30. Junio C HamanoApr 16, 2008
  31. Jeff KingApr 16, 2008
  32. Daniel BarkalowApr 16, 2008
  33. Junio C HamanoApr 16, 2008
  34. Jeff KingApr 22, 2008
  35. Junio C HamanoApr 22, 2008
  36. Daniel BarkalowApr 22, 2008
  37. Jeff KingApr 22, 2008
  38. Jeff KingApr 22, 2008
  39. Junio C HamanoApr 22, 2008
  40. Jeff KingApr 22, 2008
  41. Teemu LikonenApr 23, 2008
  42. Junio C HamanoApr 23, 2008
  43. Andreas EricssonApr 23, 2008
  44. Jeff KingApr 23, 2008
  45. Jeff KingApr 23, 2008
  46. Teemu LikonenApr 23, 2008
  47. Junio C HamanoApr 9, 2008
  48. Teemu LikonenApr 10, 2008
  49. Santiago GalaApr 12, 2008
  50. Daniel BarkalowApr 9, 2008
  51. Ingo MolnarApr 9, 2008
  52. Daniel BarkalowApr 10, 2008
  53. Junio C HamanoApr 9, 2008
  54. Jon LoeligerApr 9, 2008
  55. Nicolas PitreApr 9, 2008
  56. Jeff KingApr 9, 2008
  57. André Goddard RosaApr 9, 2008
  58. Govind SalinasApr 10, 2008
  59. Jean-Christian de RivazApr 10, 2008
  60. Sverre RabbelierApr 10, 2008
  61. git-bisect annoyancesIngo Molnar, Apr 10, 2008
  62. Christian CouderApr 11, 2008
  63. Ingo MolnarApr 11, 2008
  64. Christian CouderApr 12, 2008
  65. Junio C HamanoApr 11, 2008
  66. When a remote is added but not fetched, tell the user.Gabriel, Apr 10, 2008
  67. Johannes SchindelinApr 11, 2008
  68. GabrielApr 11, 2008
  69. Default to fetching a remote after adding it.Gabriel, Apr 11, 2008
  70. Stephen SinclairApr 11, 2008
  71. Johannes SchindelinApr 12, 2008
  72. GabrielApr 12, 2008
  73. Johannes SchindelinApr 12, 2008
  74. Teemu LikonenApr 11, 2008
  75. Junio C HamanoApr 11, 2008
  76. Sverre RabbelierApr 11, 2008
  77. Junio C HamanoApr 11, 2008
  78. Sverre RabbelierApr 11, 2008
  79. Miles BaderApr 15, 2008
  80. Default to fetching a remote after adding it.Gabriel, Apr 11, 2008
  81. Wincent ColaiutaApr 11, 2008
  82. GabrielApr 11, 2008
  83. Luciano RochaApr 11, 2008
  84. Wincent ColaiutaApr 11, 2008
  85. Jeff KingApr 10, 2008
  86. Sverre RabbelierApr 10, 2008

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.