Shawn Pearce <spearce@xxxxxxxxxxx> writes: > Petr Baudis <pasky@xxxxxxx> wrote: >> Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter >> where Junio C Hamano <junkio@xxxxxxx> 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). - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html