From: Paolo Bonzini <bonzini@gnu.org>
To: Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <junkio@cox.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: [RFC] Moving "git remote add --mirror blah" functionality to "git clone --bare --origin=blah"
Date: Wed, 23 Apr 2008 10:28:36 +0200 [thread overview]
Message-ID: <480EF334.1090907@gnu.org> (raw)
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.
Actually you don't need to add a new option. Right now, specifying
-o/--origin together with --bare would give an error; in my proposal, if
you had "--bare --origin=source" a remote would be created in the config
file like this:
[remote "source"]
url = ...
fetch = +refs/*:refs/*
2) Modify the --mirror option to "git remote add", so that it creates a
remote *acting as a mirror of this one*. The config would look like this:
[remote "mirror"]
url = ...
fetch = +refs/heads/*:refs/remotes/mirror/*
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
mirror
Now, I know that this is not what was proposed in the original --mirror
thread, and it is backwards-incompatible. On the other hand, I think it
has several advantages:
1) it does not add special cases such as "--mirror is only to be used in
a --bare repository". It moves the functionality to a combination of
options that used to give an error.
2) it provides an easy-to-use UI to create a mirror of this repository
somewhere. With a patch I already posted, "git push" would
automatically update this mirror.
3) overall, I think it makes a lot of sense: "git remote add" is about
adding one remote of many, and "git clone" is about setting up a single
special remote. Now, you can have many remotes that are
mirrored-from-here, while you can only have one remote that is
mirrored-to-here. So, I believe that "git remote add" should add
mirrored-from-here remotes, while "git clone" should be used to create a
mirrored-to-here remote.
Opinions?
Paolo
next reply other threads:[~2008-04-23 8:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-23 8:28 Paolo Bonzini [this message]
2008-04-23 9:59 ` [RFC] Moving "git remote add --mirror blah" functionality to "git clone --bare --origin=blah" Johannes Schindelin
2008-04-23 16:07 ` Junio C Hamano
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=480EF334.1090907@gnu.org \
--to=bonzini@gnu.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).