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

From: Junio C Hamano <junkio@cox.net>
Date: 2005-11-05 04:43:04
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'.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Sat Nov 05 04:44:18 2005

This archive was generated by hypermail 2.1.8 : 2005-11-05 04:44:22 EST