Re: [PATCH] Fix git-push --mirror also mirroring refs/remotes/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Markus Heidelberg <markus.heidelberg@xxxxxx> writes:

> Bryan Drewery, 10.05.2009:
>> This behavior makes no sense to me. Can we at least add a config option
>> to make it not push remotes? I push my development repository
>> to a remote private repository only as a backup, and push my master/next
>> to a public repository. I see no reason to push my 8 remotes and
>> all their branches to my backup repository.
>
> Why are you disturbed by the remotes, if it's only a backup repository
> where you don't look into in the normal case?

I suspect you got a wrong "backup".

"push --mirror" is about backing up the local repository so that other
people (most likely "you working on some other machine") who usually
interact with the current repository can instead get history from the
repository that you are pushing into, when the current repository is not
reachable for whatever reason.

In other words, "push --mirror" is not a backup in the "archive to tape
for disaster recovery" sense, but is a backup in the "you can go there in
case this is not reachable" sense.  The refspec "remote add --mirror"
creates is set up to support a backup repository in the same sense in the
opposite direction [*1*].

Now, these other people may not have any business looking into remotes
hierarchy of this repository, and we could argue that there is not much
point pushing remotes hierarchy over there (nor stash or topgit for that
matter) in a normal workflow.

But these other people can say "git fetch $here remotes/origin/master"
explicitly when fetching from this repository.  By mirroring everything
under refs/ to its --mirror backup repository, these other people can
substitute $here with its --mirror backup repository and expect it to
still work.  It would be a regression if you stop pushing the refs/remotes
hierarchy, and such a proposal must be backed by an argument that says the
benefit such a change brings in far outweighs the regression it causes.


[Footnote]

*1* If you want a "disaster recovery backup", there is always "tar".  My
recent favourite is to append into an existing squashfs image, though ;-)
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]