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

Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior

From
LTLuben Tuikov <ltuikov@yahoo.com>
Date
Jan 6, 2007, 00:32 UTC
Message-ID
<234200.4582.qm@web31806.mail.mud.yahoo.com>
In-Reply-To
<7vr6u9cann.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
Show 34 quoted lines
> Junio C Hamano <junkio@cox.net> writes:
> 
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> --- Junio C Hamano <junkio@cox.net> wrote:
> >>> 
> >>> Because [remote] is NOT about mapping.  It asks the fetch
> >>> mechanism to fetch from that remote, so the primary thing you
> >>> should look at is .url, not RHS of colon on .fetch lines.  Use
> >>> of tracking branches is strictly optional.
> >>
> >> [remote "origin"]
> >>         url = http://blah/bleah.git
> >>         fetch = +refs/heads/*:refs/remotes/origin/*
> >>
> >> This basically says: "Get it" from such and such url, where
> >> on the repo at that url, i.e. the remote side, you will
> >> find stuff in "refs/heads/", and when you get it here, locally,
> >> put it in refs/remotes/origin/.
> >
> >         [remote "origin"]
> >                 url = http://blah/blah.git
> >                 fetch = refs/heads/master
> >
> > is also fine.  The point is that you do not have to use tracking
> > branches.  ", and when you get it here, ..." part is optional.
> 
> In other words, remote.*.fetch could be spelled as mapping to
> cause them locally stored in tracking branches, but the storing
> in tracking branches is merely a side effect of a fetch, not the
> primary one.  The primary effect is to fetch the necessary
> objects and leave what was fetched in .git/FETCH_HEAD to
> communicate with later 'git pull'.  The side effect is optional,
> so is spelling remote.*.fetch as a mapping.
Oh ok -- I forgot about .git/FETCH_HEAD.
Show 18 quoted lines
> >> Yeah, but by default "refs/heads/branchA" doesn't exist (see
> >> my previous email).  It doesn't have to, since it specifies
> >> the "remote part", but that has already been handled by
> >> "[remote]".
> >
> > Obviously fetch needs to handle the remote part because that is
> > the only name it exists at the remote.  branch.*.merge is used
> > by pull, not fetch, and fetch communicates with pull by using
> > the remote name, because use of local tracking branches is
> > optional.
> 
> In other words, the remote name is the only thing that can be
> used between fetch and pull to communicate.  Fetch tells pull "I
> fetched these from the remote", and pull uses that information
> to make a merge, and the merge comment says "this merges the
> branch xyz from that repository", using the 'xyz' name used at
> the remote side, not your local tracking branch, which you may
> or may not be using.
Ok.
    Luben
Previous: Junio C HamanoNext: Luben Tuikov
Message 42 of 47 in “Docs: update cvs-migration.txt to reflect clone's new default behavior”
  1. Docs: update cvs-migration.txt to reflect clone's new default behaviorbfields@fieldses.org, Dec 31, 2006
  2. Documentation: update git-clone.txt for clone's new default behaviorbfields@fieldses.org, Dec 31, 2006
  3. Documentation: update git-pull.txt for clone's new default behaviorbfields@fieldses.org, Dec 31, 2006
  4. Documentation: update glossary entry for "origin"bfields@fieldses.org, Dec 31, 2006
  5. Documentation: remove master:origin example from pull-fetch-param.txtbfields@fieldses.org, Dec 31, 2006
  6. Documentation: update tutorial's discussion of originbfields@fieldses.org, Dec 31, 2006
  7. Junio C HamanoJan 1, 2007
  8. J. Bruce FieldsJan 1, 2007
  9. Junio C HamanoJan 1, 2007
  10. Luben TuikovJan 1, 2007
  11. J. Bruce FieldsJan 1, 2007
  12. Luben TuikovJan 1, 2007
  13. J. Bruce FieldsJan 1, 2007
  14. Luben TuikovJan 1, 2007
  15. Junio C HamanoJan 1, 2007
  16. Luben TuikovJan 1, 2007
  17. Theodore TsoJan 1, 2007
  18. Luben TuikovJan 1, 2007
  19. Theodore TsoJan 2, 2007
  20. Luben TuikovJan 2, 2007
  21. Junio C HamanoJan 2, 2007
  22. Luben TuikovJan 2, 2007
  23. J. Bruce FieldsJan 1, 2007
  24. J. Bruce FieldsJan 1, 2007
  25. Luben TuikovJan 2, 2007
  26. J. Bruce FieldsJan 2, 2007
  27. Theodore TsoJan 2, 2007
  28. Luben TuikovJan 2, 2007
  29. Junio C HamanoJan 2, 2007
  30. Luben TuikovJan 2, 2007
  31. Junio C HamanoJan 2, 2007
  32. Jakub NarebskiJan 2, 2007
  33. Luben TuikovJan 2, 2007
  34. Junio C HamanoJan 2, 2007
  35. Jakub NarebskiJan 2, 2007
  36. Luben TuikovJan 2, 2007
  37. Jakub NarebskiJan 2, 2007
  38. Junio C HamanoJan 2, 2007
  39. Luben TuikovJan 5, 2007
  40. Junio C HamanoJan 5, 2007
  41. Junio C HamanoJan 5, 2007
  42. Luben TuikovJan 6, 2007
  43. Luben TuikovJan 6, 2007
  44. Junio C HamanoJan 6, 2007
  45. Luben TuikovJan 1, 2007
  46. J. Bruce FieldsJan 2, 2007
  47. Junio C HamanoJan 2, 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.