git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Vaclav Hanzl <hanzl@noel.feld.cvut.cz>
Cc: git@vger.kernel.org
Subject: Re: Document clone of clone loosing branches?
Date: Sat, 14 Jun 2008 10:31:17 -0400	[thread overview]
Message-ID: <20080614143117.GA8640@sigill.intra.peff.net> (raw)
In-Reply-To: <20080614.150548.71104932.hanzl@noel.feld.cvut.cz>

On Sat, Jun 14, 2008 at 03:05:48PM +0200, Vaclav Hanzl wrote:

> I wander whether man git-clone is correct when it says "creates
> remote-tracking branches for each branch in the cloned repository".
> 
> IMHO remote-tracking branches in the original repository _are_
> branches and they are _not_ cloned (when using git-clone with no
> options) - maybe this is worth noting very explicitly?

The new repository has remote tracking branches of the _regular_
branches that are in the original repository. So the statement is
correct; git-clone creates remote-tracking branches, and it makes one
such branch for each branch in the cloned repository.

Unless you are complaining that it makes one for each non-remote branch
in the cloned repository. But I think it is the general pattern to refer
to things in refs/heads/ as simply unadorned "branch". If you want to
say "all refs, including remote-tracking branches", you would typically
say "refs" (which would also include tags).

> When git newby like me converts a CVS repository, containing just few
> short old branches (stable release bug fixes) and then clones it
> around, with naive belief that clone is a 1:1 copy or something close,
> nasty surprise can happen:

In that sense, clone is a bit of a misnomer, because the two _are_
different. The cloned repo has its origin pointing to the original repo,
and the origin of the original repo (and its associated tracking
branches) are forgotten.

>  - converted repository has those branches, OK
>  - clone of it also has them, but as a remote tracking branches
>  - clone of clone has it as dangling objects only (can go away later)

The clone of clone does not have dangling objects; either it sees a ref
(because it is a branch in the clone) and it grabs the objects, or it
does not see it, in which case it does not download those objects.

> Trying to play it safe, I used git-clone many times while starting
> with git, and I got really nervous when I first discovered that my old
> stable release bug fix branch is not visible in some repositories :-)

Yes, this is sometimes annoying if what you _really_ want is another
clone of the clone's origin. For me, this happens because I want to
clone Junio's git.git (to do some experimentation that might trash the
repo), but:

  - I am too lazy to type Junio's git URL
  - I want the hard-link space-saving of cloning my local repo

So I do something like:

  ref=/path/to/my/git/repo
  git clone --reference $ref `cd $ref && git config remote.origin.url`

which you can easily put in an alias.

-Peff

  reply	other threads:[~2008-06-14 14:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-14 13:05 Document clone of clone loosing branches? Vaclav Hanzl
2008-06-14 14:31 ` Jeff King [this message]
2008-06-14 20:15   ` Document clone of clone ... bug?? Vaclav Hanzl
2008-06-14 20:34     ` Jakub Narebski
2008-06-14 20:48       ` Vaclav Hanzl
2008-06-14 14:31 ` Document clone of clone loosing branches? Jakub Narebski
2008-06-14 14:44 ` Lea Wiemann
2008-06-14 21:36   ` Vaclav Hanzl
2008-06-14 22:18     ` Junio C Hamano
2008-06-15  7:18       ` Vaclav Hanzl
2008-06-14 23:03     ` Jakub Narebski
2008-06-15  8:40 ` Jakub Narebski
2008-06-15 13:05   ` [PATCH] Documentation: Note about the meaning of "clone" Robin Rosenberg
2008-06-15 13:39     ` Jakub Narebski
2008-06-15 13:52     ` Wincent Colaiuta
2008-06-15 16:31       ` Vaclav Hanzl
2008-06-15 17:03     ` Vaclav Hanzl
2008-06-15 19:12     ` Miklos Vajna
2008-06-15 20:14     ` Junio C Hamano
2008-06-15 13:05   ` PATCH] cvsimport: Clarification on the use of -r Robin Rosenberg

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=20080614143117.GA8640@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=hanzl@noel.feld.cvut.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).