git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [RFC] Moving "git remote add --mirror blah" functionality to "git clone --bare --origin=blah"
Date: Wed, 23 Apr 2008 09:07:28 -0700	[thread overview]
Message-ID: <7vhcdstv0f.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <480EF334.1090907@gnu.org> (Paolo Bonzini's message of "Wed, 23 Apr 2008 10:28:36 +0200")

Paolo Bonzini <bonzini@gnu.org> writes:

> In the thread "git remote update -> rejected" Junio and Johannes came
> to the conclusion that "--mirror means that you do not have local
> branches", because "you give control away to the other end on the ref
> namespace".  Furthermore, it was agreed that --mirror currently makes
> sense mostly (or only?) on a bare repository.
>
> From here I gather that if you have "git remote add --mirror", most
> likely the mirrored repository will be the only remote you have.
> There is in general no point in having other remotes in a bare
> repository. And so there is no loss of generality if this remote is
> the "origin" remote.
>
> Hence, my proposal is:
>
> 1) Add an option to "git clone", to be used with --bare, to create a
> mirror.  --bare already leaves the original refs in place, without
> moving them under refs/remotes/origin, so it makes sense to optionally
> create the remote.

I actually had a slightly different vision.  A mid-term goal should be to
reimplement "clone" that has a lot of code duplication with "fetch" and
"remote" in terms of "init + remote + fetch + checkout" [*1*].  For that
to happen, I suspect that "remote" needs to learn a few more tricks than
it currently knows (e.g. "figuring out the HEAD").

I would agree that it is useful for "clone" to create a bare repository in
a mode that can be used for further cloning by other repositories (perhaps
the former sits at the firewall boundary that it is cumbersome to cross by
the latter).  As you described above, we already have that (iow, "--bare").

And "remote add --mirror" would be an implementation detail to produce
such a clone.  It is mostly about fetching.

An option to add a back-up repository that you can maintain an exact
mirror of your working repository would be useful, but that is different
from what "remote add --mirror" is about.

[Footnote]

*1* In that sense, a more sensible order than rewriting "clone" in C in
its current form would be to make necessary enhancements to the components
in this sequence that need to implement clone, figure out how they should
fit together and first make "clone" a four-liner shell script. Then
rewriting the result in C may become more trivial.

  parent reply	other threads:[~2008-04-23 16:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-23  8:28 [RFC] Moving "git remote add --mirror blah" functionality to "git clone --bare --origin=blah" Paolo Bonzini
2008-04-23  9:59 ` Johannes Schindelin
2008-04-23 16:07 ` Junio C Hamano [this message]
2008-04-23 16:56   ` Daniel Barkalow
2008-04-23 22:25     ` Jeff King
2008-04-23 20:06   ` Paolo Bonzini
2008-04-23 22:02     ` Junio C Hamano
2008-04-23 22:42       ` Johannes Schindelin
2008-04-24  6:23       ` Paolo Bonzini

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=7vhcdstv0f.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bonzini@gnu.org \
    --cc=git@vger.kernel.org \
    /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).