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

[Junio C Hamano <junkio@cox.net>]

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'.