From: chris Date: Thu, 31 Mar 2011 02:44:49 GMT Subject: Re: [PATCH 2/3] remote: separate the concept of push and fetch mirrors Message-ID: In-Reply-To: <7v62r0meok.fsf@alter.siamese.dyndns.org> Junio C Hamano pobox.com> writes: > > What would we call a person who first asks "I want a push mirror to save > away my work" and then says "now let's fetch from there", without > realizing that such a fetch will obliterate his work? I agree that it > probably is asking a bit more than "common sense"; it perhaps requires an > ability to think for 5 minutes what oneself is doing . If I have to stop and think for 5 minutes before I execute any git command, I think there may be an issue with the tool. :) That said - the above thoughts were never the source of my surprise. The only surprising aspect of this whole thing was the behavior of branch.autosetupmerge when a 'mirror' remote existed. Essentially the existence of the mirror remote turned all local branches into remote-tracking branches - that is surprising. I have no issue with --mirror having its current behavior (although the proposed changes certainly are more explicit and therefore clearer), however, I propose that branch.autosetupmerge should ignore remotes with mirror = true. I'd also propose that when setting up a --mirror, if the repository is not bare, that the fetch refs be set to "refs/*:refs/*" rather than "+refs/*:refs/*". With those two changes, I get the functionality I want without surprises. I use the mirror for synchronizing "local" work between my workstations (home/office). So, I use the fact that I can fetch and pull from the mirror. chris