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

Re: Document clone of clone loosing branches?

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 14, 2008, 23:03 UTC
Message-ID
<200806150103.02260.jnareb@gmail.com>
In-Reply-To
<20080614.233645.71097102.hanzl@noel.feld.cvut.cz>
Vaclav Hanzl wrote:
Show 13 quoted lines
> Jakub Narebski wrote:
>>
>> The idea is for git-clone to clone (by default) _your_ work, not sb
>> else work.  Think about two repositories, fetching from each other:
>> you don't want for branches to proliferate like mad, remote of remote,
>> then remote of remote of remote, and ad infinitum.
>> 
>> Besides there is I think implicit assumption that public repositories
>> one might want to clone are _bare_ repositories, 1:1 or mirror
>> refspecs, which simply do not contain remote tracking branches. 
> 
> Yes. It would be no shame if an explanation like this made it to 'man
> clone'?

The question of course is _what_ to put into git-clone(1), what to generic documentation in git(1), and what in "Git User's Manual".

> After all, how many other commands do distinguish regular branches and
> remote tracking branches?

Errr... many of them? git-branch treats regular branches (refs/heads/*) and remote-tracking branches (refs/remotes/<remotename>/*) differently (compare "git branch" and "git branch -r", and "git branch -a"). git-checkout treats regular branches (can checkout) different from other refs, including remote-tracking branches (result in detached HEAD).

> Even if there are any other (I do not know), 
> git-clone is likely the most prominent of them and 'man git-clone' is
> quite good place to document this. Unless it is explained in 'man git'
> itself (I think it is not now).
I'm not sure how it is put in documentation, but I wouldn't wonder
if it is not dicumented, because most of gitters who can write this
documentation do know the difference between regular branches and
remote-tracking branches, and know recoomended workflows and best
practices.
 
Show 6 quoted lines
> (Thought I am quite happy with UNIX tradition of very exact and very
> condensed man pages, up to the point of being a hard puzzle, and I
> agree that man pages are no tutorial, in this case I would be happy to
> see 'regular branches' and 'remote tracking branches' clearly
> distinguished in 'man git-clone' itself, without an implicit reference
> to 'usual' meaning of words among geeks.)

So, what should be mentioned ar two facts, I think. (a) that git-clone copies only regular branches and tags; it does not copy remote-tracking branches, it does not copy stash, it does not copy reflogs, it does not copy StGIT stacks... (b) that recommended workflow (best practice) is to have public published repository which is bare clone (1:1 correspondnce) of interesting subset of refs.

-- 
Jakub Narebski
Poland
Previous: Vaclav HanzlNext: Jakub Narebski
Message 11 of 20 in “Document clone of clone loosing branches?”
  1. Vaclav HanzlJun 14, 2008
  2. Jeff KingJun 14, 2008
  3. Vaclav HanzlJun 14, 2008
  4. Jakub NarebskiJun 14, 2008
  5. Vaclav HanzlJun 14, 2008
  6. Jakub NarebskiJun 14, 2008
  7. Lea WiemannJun 14, 2008
  8. Vaclav HanzlJun 14, 2008
  9. Junio C HamanoJun 14, 2008
  10. Vaclav HanzlJun 15, 2008
  11. Jakub NarebskiJun 14, 2008
  12. Jakub NarebskiJun 15, 2008
  13. Documentation: Note about the meaning of "clone"Robin Rosenberg, Jun 15, 2008
  14. Jakub NarebskiJun 15, 2008
  15. Wincent ColaiutaJun 15, 2008
  16. Vaclav HanzlJun 15, 2008
  17. Vaclav HanzlJun 15, 2008
  18. Miklos VajnaJun 15, 2008
  19. Junio C HamanoJun 15, 2008
  20. PATCH] cvsimport: Clarification on the use of -rRobin Rosenberg, Jun 15, 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.