From: Shawn Pearce <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCH] Added --mirror-all to git-fetch.
Date: Wed, 20 Sep 2006 12:49:12 -0400 [thread overview]
Message-ID: <20060920164912.GD23260@spearce.org> (raw)
In-Reply-To: <7v1wq6jy3q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I realize I am going around in circles, but Pasky's "remotes/"
> argument made me realize that this mirroring is not much more
> than "fetch --force --all". I initially had an impression that
> this was for only strict mirroring where you do not even want
> your own "origin", but if you arrange the .git/remotes/origin
> file the right way, "fetch --force --all" (if you remembered to
> put '+' in front of the refspecs, even without --force) would
> what --mirror-all would do wouldn't it?
I started this change with '--all' and realized that ideally you
want '--all' to copy all available refs/heads/* from the remote to
refs/remotes/<name>/* here. You want to create any new branches
which the remote has introduced since your last fetch.
You probably don't want to force a non-fast forward unless there's a
'+' in the corresponding Pull line of remotes/<name> or if --force is
used. However you probably also want to delete any removed branches.
Which I think is quite different from a mirror. A mirror wants to
replace the entire ref namespace with what's on the remote as it
has no need for a local namespace of its own.
Originally I gave Pasky a one-liner on #git:
git fetch --force origin $(git ls-remote origin \
| awk '{if(!/\^{}$/){print $2":"$2}}')
but he expressed interest in it being a native feature of the
core-Git fetch Porcelain. To be honest I disagreed with him but
submitted the patch anyway.
I think --all copying into .git/refs/remotes/<name>/* makes perfect
sense.
And I think this mirror thing may make more sense as a small wrapper
around git-fetch. A wrapper that checks for:
- its running in a bare repository;
- it has a single remote named origin;
- HEAD isn't a symlink or a symref (its a normal ref in its
own right);
- git-mirror.permitted is true in the config file.
--
Shawn.
next prev parent reply other threads:[~2006-09-20 16:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-19 23:28 [PATCH] Added --mirror-all to git-fetch Shawn Pearce
2006-09-19 23:41 ` Petr Baudis
2006-09-20 16:06 ` Junio C Hamano
2006-09-20 16:14 ` Petr Baudis
2006-09-20 16:21 ` Shawn Pearce
2006-09-20 16:34 ` Junio C Hamano
2006-09-20 16:49 ` Shawn Pearce [this message]
2006-09-20 17:13 ` Junio C Hamano
2006-09-20 17:31 ` Shawn Pearce
2006-09-20 17:50 ` Junio C Hamano
2006-09-20 18:42 ` A Large Angry SCM
2006-09-20 18:29 ` Petr Baudis
2006-09-20 21:36 ` Junio C Hamano
2006-09-20 21:42 ` Shawn Pearce
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=20060920164912.GD23260@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=pasky@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.