Re: [PATCH 2/3] remote: separate the concept of push and fetch mirrors
- From
- chris <jugg@hotmail.com>
- Date
- Mar 31, 2011, 02:44 UTC
- Message-ID
- <loom.20110331T040801-714@post.gmane.org>
- In-Reply-To
- <7v62r0meok.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
Show 6 quoted lines
> > 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