Git Frage: Wozu eine Merge-Basis

[Daniel R. (dan066)]

Im schönen Git-Buch von Jon Loeliger, das ich gerade lese, steht, dass 
jeder Commit auf ein Tree-Objekt zeigt, das das komplette Repository 
darstellt. (Git speichert Dateien bei Änderung komplett neu, anders als 
SVN welches nur die Unterschiede speichert um Platz zu sparen).
Will man nun zwei Branches zusammen-mergen, müsste es dann doch 
ausreichen beide Branch-Heads zu vergleichen und die Unterschiede in 
einen der beiden zu integrieren.
Stattdessen lese ich, dass eine Merge-Basis nötig ist, bei der beide 
Branches auf dem selben Stand waren, um alle Commits seit dem Zeitpunkt 
einzeln? in einen der beiden Branches zu integrieren.

Warum ist das nötig, wenn doch jeder Commit alle benötigten Daten als 
Kopie enthält? Es klingt so, als ob Git in jedem Commit nur Unterschiede 
speichern würde, obwohl es doch alle Daten in Kopie speichert.

Gibt es hier jemanden, der verstanden hat, wie das genau abläuft?

[proggen (Gast)]

https://git-scm.com/book/de/v1/Git-Branching-Einfaches-Branching-und-Merging

[JJ (Gast)]

Daniel R. schrieb:
> Git speichert Dateien bei Änderung komplett neu

Ich stelle diese Prämisse in Frage und damit hat sicher der Rest der 
Frage erledigt.

zusätzlich möchte ich dieses Video empfehlen:
https://www.youtube.com/watch?v=1ffBJ4sVUb4

[Daniel R. (dan066)]

JJ schrieb:
> Daniel R. schrieb:
>> Git speichert Dateien bei Änderung komplett neu
>
> Ich stelle diese Prämisse in Frage und damit hat sicher der Rest der
> Frage erledigt.
>
> zusätzlich möchte ich dieses Video empfehlen:
> https://www.youtube.com/watch?v=1ffBJ4sVUb4

Danke für den Link.
Tatsächlich soll für jede veränderte Datei in einem Commit ein neues 
Blob-Objekt erstellt werden. Der neue Tree im Commit zeigt dann auf die 
neuen Blobs veränderter Dateien und auf die alten Blobs unveränderter 
Dateien.

Laut dem Buch:
-Speichert SVN (u.a.) Veränderungen an Dateien um Speicherplatz zu 
sparen.

-Müssen bei SVN um ein Diff zwischen zwei Commits zu ermitteln, 
sämtliche dazwischenliegenden Commits angesehen werden, alle Diffs 
zwischen diesen gesammelt werden und zusammen gemerged werden, um dem 
Benutzer den Gesamt-Diff präsentieren zu können. (Kostet viel Zeit).

-Ist jeder Tree in einem Git-Commit unabhängig von allen anderen Trees.

-Gibt es im Git-Repository keine Diffs (Diff-Objekte wie bei SVN).

-Benötigt Git für ein Diff zweier Commits keine dazwischenliegenden 
Commits. Git arbeite direkt auf Snapshots der Komplettzustände beider 
Versionen.

Dieser einfache Unterschied im Speichersystem sei einer der wichtigsten 
Gründe dafür, dass Git so viel schneller ist als andere 
Versionskontrolsysteme. (Sinngemäß übersetzt).

[Daniel R. (dan066)]

Dies hat meine Frage beantwortet:

https://www.slideshare.net/epatey/perforce-convergence-vs-divergence/10

[Skippy (Gast)]

Daniel R. schrieb:
> Laut dem Buch:

Wenn das so wirklich im Buch steht: wegwerfen :)

Probier es mal hiermit: https://www.atlassian.com/git/tutorials

Git speichert auch nur diffs, interessiert aber nicht wirklich fuer 
Dateien/Verzeichnisse sondern eben nur fuer den Inhalt.

Hier mal etwas bunte Doku zu deiner ersten Frage bez. der "Merge Basis":
https://www.atlassian.com/git/tutorials/using-branches

[Daniel R. (dan066)]

Skippy schrieb:
> Git speichert auch nur diffs, interessiert aber nicht wirklich fuer
> Dateien/Verzeichnisse sondern eben nur fuer den Inhalt.

Ich habe diese Seite gefunden:
https://stackoverflow.com/questions/10398744/does-git-store-diff-information-in-commit-objects

Auf der steht:
Git stores references to complete blobs and this means that with git, 
*only one commit is sufficient to recreate the codebase at that point in 
time*. Git does not need to look up information from past revisions to 
create a snapshot.


Dieser Link:

https://stackoverflow.com/questions/4129049/why-is-a-3-way-merge-advantageous-over-a-2-way-merge

hat mir geholfen zu verstehen, dass die Merge-Basis nötig ist um bei 
einem Merge von zwei Branches herauszufinden welcher der vier Fälle wahr 
ist:
1) Eine Zeile (oder Wort, Datei, etc.) ist in beiden Branches noch im 
Originalzustand. Wird dann so ins Merge-Ergebnis übernommen.
2) Eine Zeile ist in einem Branch noch im Originalzustand, im anderen 
verändert. Dann wird die veränderte Variante ins Merge-Ergebnis 
übernommen.
3) Eine Zeile wurde in beiden Branches verändert und ist in beiden 
gleich und wird ins Merge-Ergebnis übernommen.
4) Eine Zeile wurde in beiden Branches verändert und zwar in 
unterschiedlicher Weise. Das ist dann ein Merge-Konflikt.