All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.