Jeff King <peff@xxxxxxxx> writes: > git-remote currently has one option, "--mirror", which sets > up mirror configuration which can be used for either > fetching or pushing. It looks like this: > > [remote "mirror"] > url = wherever > fetch = +refs/*:refs/* > mirror = true > > However, a remote like this can be dangerous and confusing. When --mirror was introduced at 3894439 (Teach "git remote" a mirror mode, 2007-09-02), it was only about fetching into a bare repository from another repository and there wasn't any confusion. I knew about this potential confusion when we applied 84bb2df (Add a remote.*.mirror configuration option, 2008-04-17), but chose to be lazy and ignored the issue, thinking that users are intelligent enough not to mix these obviously incompatible modes of operation. If a repository is a mirror to fetch from somebody else, you wouldn't develop in it in the first place, and you would definitely not push it back to where you are mirroring from. If a repository is mirrored into somewhere else to publish your work in there, you wouldn't be fetching back from there to obliterate your work. Being explicit like your series does is much safer than relying on "common sense". I briefly wondered if this affects one use case where you want to configure a bare repository at your firewall boundary as a relay that mirrors an external public repository of somebody else by fetching and then publishes that to a repository internal to your network by pushing, but in that case you would have two remotes (the external --mirror=fetch one, and the internal --mirror=push one) that are separate, so it is not an issue. Thanks for cleaning up the two-year old mess. -- 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