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

From: Junio C Hamano <junkio@cox.net>
Date: Sep 20, 2006, 16:34 UTC
Message-ID: <7v1wq6jy3q.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060920162145.GA23260@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 22 quoted lines

> Petr Baudis <pasky@suse.cz> wrote:
>> Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter
>> where Junio C Hamano <junkio@cox.net> said that...
> [snip]
>> >  (2) Although there is no inherent reason not allowing a working
>> >      tree associated with the repository that is kept updated
>> >      this way, the user will be utterly confused in a working
>> >      tree whose current branch head is updated like this, until
>> >      the working tree and the index is matched to the updated
>> >      HEAD.
>> 
>> git-fetch --mirror-all can still be very useful even with a working copy
>> if you are keeping all the remote heads in .git/refs/remotes/. I'd
>> venture to say that in that case, this is frequently what you actually
>> want when fetching from the repository (given that you have already let
>> git clone do that once).
>
> I think that's more `git fetch --all`.  You are pulling every remote
> head available at a given remote into a subdirectory of your own ref
> space.  That's rather different than replacing your entire ref space
> with the one available on the remote, which is what --mirror-all
> is doing and what you wanted for the hosting you are offering.

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?

Having said that, I am not sure if "fetch --all" should delete branches that do not exist on the remote end. For mirroring, I definitely would want the tool to delete them, and that is one of the reason I feel this is much more similar to git-clone than git-fetch, unless it is a separate command (perhaps git-mirror).