Re: [PATCH] Added --mirror-all to git-fetch.

From: Junio C Hamano <junkio@cox.net>
Date: Sep 20, 2006, 17:13 UTC
Message-ID: <7vac4uihr3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060920164912.GD23260@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 8 quoted lines

> 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.

I think we are in agreement here.

> 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.

If you have remotes/origin that does not use the refs/remotes hierarchy, does not copy master->origin (iow, the assumption that "origin" branch is to be merged into local "master") but copies remote master to local master, and forces all refs by default, then your local ref namespace is effectively a mirror of the remote, so it is very tempting to think --mirror is a logical extension of "fetch --all".

Except that new refs are not created and old refs are not deleted. And these two are rather big exceptions.

If we are to have another command (git-mirror which is a thin wrapper around git-fetch as you propose later), these two exceptions would be cleanly handled there. Otherwise, we would need to give the command a hint (git-mirror.permitted) to allow them to be done in addition to the usual "fetch --all", but then we would end up doing the equivalent of your one-liner anyway, so there is not much point having it in git-fetch. So I am in favor of your thin-wrapper idea.

> Originally I gave Pasky a one-liner on #git:
>
>   git fetch --force origin $(git ls-remote origin \
>       | awk '{if(!/\^{}$/){print $2":"$2}}')

Which sounds a very sane thing to do, especially given git is designed to be scripted this way.

> 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;

Ok.

> 	- it has a single remote named origin;

Do you mean ".git/remotes must have only one file 'origin' and nothing else", or do you mean "There must be .git/remotes/foobla for 'git-mirror foobla' to work"?

> 	- HEAD isn't a symlink or a symref (its a normal ref in its
> 	  own right);

Why? Usually HEAD is a pointer to the active branch. I consider it is a bug in the upload-pack protocol not to convey that information (but that is a separate topic).

> 	- git-mirror.permitted is true in the config file.

Ok.