N
hustbaer schrieb:
OK, das verschiebt den Aufwand auch nur
(Wobei es natürlich nett ist wenn man nicht beim committen warten muss, sondern die Angelegenheit wenn man möchte per cron/... über Nacht erledigen lassen kann!)
Ja, einerseits das und andererseits lässt sich das auch extrem gut konfigurieren. Bei jedem Aufruf kannst du einstellen, wie viel Zeit die Delta-Compression brauchen darf, wie groß die Suchtiefe ist und und und. Der Cronjob darf dann zB. viel länger brauchen als dein Laptop oä. Dass überhaupt Packfiles angelegt werden, ist eine reine Optimierung; an sich könnte man das auch komplett weglassen.
Wie werden eigentlich Änderungen remote übertragen? Also wenn man nen Pull macht - keine Ahnung wie das in GIT-speak genau heisst ("SVN update" halt).
Ja, "git pull". Wenn du es genau wissen möchtest, lies am besten selbst nach; ganz grob funktioniert es bei Pulls ungefähr so (hoffentlich nicht zu sehr vereinfacht):
Git holt sich die SHAs aller Branches am Remote.
Git checkt, welche Objekte lokal schon vorhanden sind (SHA) und erstellt eine Liste von Objekten, die es gerne vom Server hätte.
Git sagt dem Server, welche Objekte es schon hat und welche es noch braucht.
Der Server antwortet dem Client mit einem passenden Packfile, in dem genau die fehlenden Objekte enthalten sind.
Früher gab es einen recht primitiven Commit-Walker, der im wesentlichen rekursiv referenzierte Objekte geholt hat, die lokal noch nicht vorhanden waren. Problem dabei war, dass man bei großen Repos entweder große Mengen von losen Objektfiles einzeln herunterladen musste, oder aber ein paar wenige fette Packfiles herunterladen musste, auch wenn man nur wenige Objekte davon wirklich noch nicht hatte.
