Is het "veilig" om kloon van de ene repo en oorsprong naar een andere te sturen?

Dus ik heb de neiging om een ​​recente kloon van een repo te hebben die ik nodig heb om "zeer dichtbij" te werken op het netwerk (vaak op de lokale schijf). Er is ook een "officiële" server waarvan mijn werkstroom echt de oorsprong wil zijn, maar deze is vaak erg traag (hetzij omdat deze overbelast is, hetzij op een ver netwerk, of beide).

(deze lokale repo is een kloon van de officiële server die neigt om een ​​week of twee verouderd te zijn, maar de repo is erg groot en heeft ongeveer een decennium aan geschiedenis geïmporteerd uit oudere VCSes, dus de lokale kloon plus ophaalactie van de afstandsbediening is een stuk sneller)

Als ik git clone -o local/path/to/repo en dan git remote add-f origin URI-for-offical-repo zal ik eindigen met hetzelfde (*) git clone URI-for-offical-repo zou me hebben gegeven?

Ik ben vooral op mijn hoede voor subtiele verschillen die een push van mijn repo anders kunnen maken. Ook als ik gebruik maak van deze methode om de kloon te versnellen, kan de "lokale" repo zijn gemaakt met deze methode, misschien voor meerdere generaties.

(*) hetzelfde plus de extra externe naam "lokaal", en alles dat niet van lokaal naar de officiële server was gepusht.

4

2 antwoord

Kort antwoord: Ja, waarschijnlijk.

Lang antwoord: de "oorsprong" is gewoon een alias voor waar je normaal gesproken zou willen pushen. Zolang de nieuwe bestemming gerelateerd is aan de repository waar je aan hebt getrokken (of een lege repository), en je hebt schrijftoegang, moet het veilig zijn.

OPMERKING: Ik heb niet echt overwogen dat uw voorbeeld van een "pseudo-code" -commando verstandig is. Maar het concept van klonen en vervolgens het wijzigen van de URL voor de 'oorsprong' is een verstandig concept. Ik heb het zelf gedaan wanneer serveradressen zijn verplaatst of ik heb besloten mijn openbare reporocatie te wijzigen, enzovoort.

Let op, als de nieuwe oorsprong GEEN volledig lege repository is, of een oude kloon van uw lokale repo (zonder nieuwere commits dan op uw lokale repository), met gebruik van

git push --mirror #e.g. implicitly to "origin"

kan takken op de afstandsbediening overschrijven en weggooien als je volledige schrijftoegang hebt. (Dit heb ik ook kunnen doen, wanneer ik achteloos en .git/config-gegevens van één repo naar een niet-verwante repo kopieer en plak. [Gelukkig had het voldoende up-to-date klonen, maar ik was zweten gedurende enkele seconden wanneer het wissen van berichten over mijn scherm scrolde;)])

5
toegevoegd
De nieuwe oorsprong is nooit helemaal leeg en de lokale repo is altijd een oudere kloon van de "nieuwe" oorsprong (ik heb de vraag bijgewerkt om dat weer te geven). Ik doe echter niet "git push - mirror", alleen "git push" en "git push origin CURRENT-BRANCH"
toegevoegd de auteur Stripes, de bron

What you are doing looks to be fine but you might be looking for the --reference option that was added to git clone some time ago. If there is a local copy this makes it very quick to create a new clone using the reference repository packs and then just updating from the network. eg: git clone --reference ./oldercopy $url newcopy

Voor uw huidige schema - mits de tree's gerelateerd zijn - is er geen probleem om de url's voor de afstandsbedieningen te veranderen. Als ze geen verband houden, zullen allerlei onaangename foutmeldingen verschijnen.

3
toegevoegd
Het is mijn begrip dat als je --reference gebruikt en je verwijdert de referentie repo (of een gc of filter uitvoert) dat er slechte dingen kunnen gebeuren. Ik wil de slechte dingen echt vermijden.
toegevoegd de auteur Stripes, de bron
Ik controleerde dit - en je hebt gelijk. Als de referentie-repository verdwijnt, heeft je nieuwe kloon problemen. Het kan worden opgelost, maar het ziet er nogal angstaanjagend uit.
toegevoegd de auteur patthoyts, de bron