Ich habe vor einem Jahr ein Git-Repository bei Github eingerichtet und sychronisiere Markdown-Datei über Git. Das ist nur für meine Texte gedacht und nicht zum Programmieren. Das funktioniert insgesamt auch gut. Einmal im Monat gibt es seltsame Konflikte, weil noch eine Datei im Papierkorb ist oder keine Leerzeile am Ende einer Datei, aber ok.

Nun habe ich festgestellt mit "git log datei.md" und "tig", dass ich eine riesengroße Historie angehäuft habe. Wie lösche ich diese Historie ganz oder teilweise? Ideal wäre beispielsweise nur die letzten drei Commits zu behalten. Meine Versuche mit "git rebase -i HEAD~3 datei.md" funktionieren nicht.

Ich benutze bislang für Git nur Terminal. Gestern habe ich testweise Sublime Merge installiert.

Kann mir jemand helfen? Da Git für das Programmieren genutzt wird, sind die Hilfe-Seiten überhäuft mit Warnungen, da die Historie meist eben nicht gelöscht werden soll. Und bei den Git-Bezeichnungen blicke ich nicht durch.

Also falls du dauerhaft keine Historie willst, ist git wahrscheinlich nicht das richtige Tool für deine Zwecke - git beruht ja im kern auf der history, deswegen ist das Historie umschreiben ja auch so ein aufwand 🫨

Rein technisch kannst du das machen, aber vielleicht wäre Dropbox und manuelles löschen der alten Versionen einfacher?

Was du im Kern machen müsstest:
https://stackoverflow.com/questions/11929766/how-to-delete-all-git-commits-except-the-last-five

Praktisch löscht du damit dann nicht die alten commits, sondern machst einfach eine neue Historie auf, die nur die besagten vier commits enthält.


Bisschen off-topic, aber warum genau willst du die Historie loswerden?

Danke, der Link sieht schon passend aus.Die Dateien werden auch über Devonthink indiziert. Ich fühle mich wohler bei dem Gedanken, dass ich die Synchronisation selbst anstoße. Daher Git. Ich könnte auch ChronoSync nehmen, aber Git gibt es für alle Geräte.Für eines der Repositories mit 200 Dateien habe ich jetzt 1058 Einträge nach einem Jahr. Gut, Markdown nimmt nicht wirklich viel Platz weg. Aber einen Nutzen in ein Jahr alte Einträge sehe ich auch nicht.
Diese Woche wollte ich tatsächlich die Dateien mit einer App (Shellfish) synchronisieren. Durch die Vielzahl der kleinen, nicht sichtbaren Dateien dauerte das ungewöhnlich lange. Da dachte ich, dass ich das mal aufräume - was aber offenbar nicht so einfach ist.Geht das? Ich hatte auch überlegt, ob die Hauruck-Methode funktioniert. Datei duplizieren, alte Datei löschen?

Indiziert oder synchronisiert? Kenne Devonthink nur vom Hörensagen.

Ich glaube git ist das richtige Tool, wenn Du mit der Historie leben kannst, aber ich versuche nochmal bisschen auszuführen, dann kannst du es vielleicht selbst auch ein bisschen besser einschätzen.
Also Dein von Git verwalteter Ordner besteht, ohne dass Du das siehst aus zwei Teilen: der Working Area und dem Repository.

Du hast in einem Ordner, der durch git verwaltet wird, einen Ordner Namens: ".git", das Repository — dort liegt die Historie in Form komprimierter Änderungssets (sogenannte Deltas) vor, wenn Du in einer Datei also nur wenige Buchstaben änderst, kostet die Aufnahme dieser Änderungen nicht wirklich viel Speicher.

Neben dem Ordner ".git" liegt in Deinem Working Directory ein "Schnappschuss" des aktuell ausgecheckten Commits.
Dieser Schnappschuss wird zusammengebaut aus der Historie aller vorherigen Commits, deswegen brauchst Du auch normalerweise immer die gesamte Historie — nur so kann git den gewünschten Snapshot "herstellen", indem es ausgehend vom 1. Snapshot alle Änderungen "abspielt". Und deswegen ist auch History umschreiben — oder in Deinem Fall einfach eine komplette neue Historie schreiben, die zufällig die letzten 5 Snapshots beinhaltet — ein so aufwendiger Prozess.

Warum synchronisierst Du mit einer App?
Ein Synchronisieren über git bedeutet nämlich nicht: alles von X nach Y kopieren, sondern eben nur die Commits, die Du bisher nicht in Y hast, der Prozess ist normalerweise zügig und sehr effizient.

Das funktioniert dann über git push / pull — dort werden die beteiligten Historien erst ver- und dann angeglichen.
Normalerweise hast Du dann einen zentralen Platz (z.B. GitHub oder einen eigenen Server) auf dem Du das Repository bereithältst und Deine Änderungen mit dem zentralen Index abgleichst.

Und weil dieser Ver- und Angleich darauf beruht, dass beteiligte Repositories auf einem gemeinsamen Commit basieren, ist das Umschreiben der Historie außerdem nicht empfehlenswert, weil dann funktioniert diese Synchronisation nicht mehr.
Nein, das funktioniert nicht, git vergleicht einfach den ausgecheckten Snapshot mit dem Index, eine duplizierte Datei ist dann keine Änderung, weil der Stand dieser Datei ja bereits im Index ist.

Ich würde vorschlagen, falls Du Dich mit git und der Historie nicht anfreunden kannst, dupliziere Deinen Ordner jedes Mal, wenn Du einen Snapshot anlegen willst, und löscht einfach die älteren Snapshots des Ordners manuell — synchronisieren kannst Du dann weiterhin von Hand, mit Shellfish oder z.B. über Dropbox.


Und wenn Du gerne Git behalten willst, inklusive Historie, beim Synchronisieren an bestimmte Ort aber nicht die ganze Historie mitnehmen willst, kopierst Du dorthin einfach alles außer Deinen ".git"-Ordner.

Sorry, die Antwort ist etwas lang, ich hoffe einigermaßen verständlich und inhaltlich nicht so krass vereinfacht, dass sie falsch wurde.

Super, danke für die Erläuterung. Der Hinweis auf den .git-Ordner löst eigentlich schon mein Problem - die Lösung ist so einfach ...

Die ganze Historie ist also .git-Ordner? Das vereinfacht Vieles. Ich sehe gerade, dass mehr als 95 % des Speicherbedarfs vom .git-Ordner belegt wird.

Wie gesagt, bislang funktionierte der git sync (push/pull) zumeist ganz einwandfrei zwischen bis zu drei Geräten. Den Sync mit Shellfish hatte ich nur ausprobiert. Dann müsste ich, falls ich einen Sync-Dienst nutzen möchte, lediglich das .git-Verzeichnis ausklammern. Shellfish greift von iOS auf MacOS per ssh zu, kann aber Dateien vom Mac offline halten - das habe ich mit Sync bezeichnet.

Ich hatte noch die Variante gefunden, dass mit "squash" commits zusammengefasst werden sollen. Aber entsprechende Befehle wurden bei meinem Repository bislang beharrlich ignoriert.

Ganz genau, im ".git" passiert die ganze Magie
Das heisst, ohne .git kein push, pull, commit usw.

Genau, dann synchronisierst du – in Git-Lingo ausgedrückt – nur dein Working Directory vom Mac zum iPhone. Wenn du anschließend Änderungen zurück synchronisieren möchtest, kopierst du diese vom iPhone ins Working Directory auf dem Mac. Danach führst du auf dem Mac den 'git commit' und 'git push' aus, und auf den anderen Geräten mit .git entsprechend den 'git pull'.Ja mit squash kannst du mehrere Deltas zu einem Delta zusammenfassen, das spart aber jetzt gar unbedingt Speicherplatz — es sei denn die Deltas haben viele Überlappungen — sondern macht die Historie "schöner zu lesen".

Aber auch 'Squash' ist ein Befehl, der die Historie potenziell umschreibt; deswegen ist er aus Git-Sicht nur in bestimmten Fällen sinnvoll. Bei der Softwareentwicklung hast du zum Beispiel eine Menge Änderungen von einem anderen Nutzer: Er möchte einen neuen Knopf (Commit 1), die dazugehörigen Funktionen (Commit 2) und die entsprechenden Tests (Commit 3) einbauen. Brauchst du diese Änderungen jedoch nicht einzeln in deiner Historie, kannst du sie beim Einfügen in deine Historie 'squashen' – aber auch das ist für deinen Fall wahrscheinlich unbrauchbar

Das (Working Directory vom Mac zum iPhone) scheint gut zu funktionieren und ist für mich die passende Lösung. Vor allem da Änderungen per iPhone doch eher selten sind. Die Kombi Shellfish/Working Copy ist auch für Git ausgelegt. Gerade hat ein weiterer "Squash"-Versuch schon einen Totalschaden verursacht. Aber wozu hat man Time Machine ... Ich probiere weiter vorsichtig, wie Git funktioniert; ansonsten gilt erstmal "never change a running system".
Danke.

Gern geschehen - ich benutze ja schon sehr lange geht, aber es gibt Sachen die muss ich auch immer wieder nachgucken - aber wozu hat man Google und Foren 😅