Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories

From: Junio C Hamano <junkio@cox.net>
Date: Nov 4, 2005, 17:43 UTC
Message-ID: <7vvez8wbpz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200511041701.48881.Josef.Weidendorfer@gmx.de>

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> ... One difference of cloning with GIT vs. with
> Cogito is that Git always clones all remote branches. This can
> be limiting if you want to work with multiple repositories,
> but allows you to immediatly work with all the branches.

Three points, and two footnotes.

. After a git clone, you can still fetch from non-origin
  repository; you can also set up .git/remotes/somewhere-else if
  you pull from the non-origin repository regularly, so it is
  not really "limiting".  It is just being slightly less
  convenient, in that setting up for the origin is done for you
  by clone [*1*] while you have to arrange for non-origin
  repository yourself afterwards.

. The namespace under refs/heads is and always will be an issue.
  It is a local matter and how remote branches are named should
  not dictate what local branch names you can use in your
  repository, but that essentially is what happens after
  git-clone to users who do not rename those branches from the
  initial cloning.

  I once considered to give an option to clone to map the origin
  heads to .git/refs/heads/origin/{master,maint,pu,...}.  In
  hindsight that might have been cleaner.  Instead I just followed
  what Cogito already established, and mapped remote "master" to
  "origin".

. The namespace under refs/tags theoretically also has the same
  issue, but I suspect it would not matter too much in practice.
  The tags people fetches from remote tend to be release-point
  tags (e.g. v2.6.14) whose names implicitly follow an obvious
  (to humans) naming convention; when you name your temporary
  anchor points using lightweight tags, you can easily avoid
  name clashes with those "for other people" tags [*2*].

[Footnotes]

*1* Actually, even the setting up for the origin is done only halfway -- it only arranges 'git fetch/pull' to fetch from the master branch, and other branches are not tracked unless you explicitly arrange them to be. This is somewhat deliberate; the refs/ namespace management is a local matter and you do not necessarily want to keep tracking all the branches from origin.

*2* This becomes somewhat problematic when the tool automatically follows/fetches tags, and that is why git-core barebone Porcelainish requires an explicit 'git fetch --tags'.