Probleme mit Git

[Pitwheazle]

Ich hätte da gerne wieder mal ein Problem:
In meinem Rechentrainer habe ich eine neue Aufgabenkategorie ergänzt. Den geänderten Code pushe ich normalerweise auf Github und pulle ihn von uberspace aus. Wie ich es von euch gelernt habe, habe ich die Datenbank in gitignore aufgenommen und das mit dem Synchronisieren hat auch immer prima funktioniert - heute nicht. Git beschwert sich, dass eine Datei zu groß sei:

Code: Alles auswählen

> git push origin master:master
remote: error: Trace: c34dfe982e90265f7146014bd14c63f8f42668dfadb49c6ab1d54c6b2874a5da        
remote: error: See https://gh.io/lfs for more information.        
remote: error: File db.sqlite3 aus Uber is 191.59 MB; this exceeds GitHub's file size limit of 100.00 MB        
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.        
To https://github.com/pitweazle/rechentrainer.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://github.com/pitweazle/rechentrainer.git'

Meine db.splite3 Datei auf meinem Computer hat nur etwa 1MB, die auf uberspace ist natürlich größer.
Woher kommt die Fehlermeldung:

Code: Alles auswählen

remote: error: File db.sqlite3 aus Uber is 191.59 MB

In meinem Repository auf Github liegt auch keine Datebank.
Hat jemand eine Idee?
Ansonsten wünsche ich euchg schon mal einen guten Rutsch in 2025!

[sparrow]

Die Fehlermeldung ist doch recht eindeutig. Du möchtest eine Datei mit dem Namen "db.sqlite3 aus Uber" in dein Repository pushen. Und die ist zu groß.

[snafu]

Die Fehlermeldung ist doch recht eindeutig.

Die Frage war vermutlich falsch gestellt. Ich schätze, es geht darum, wie die Datei da beim Pushen reingekommen ist.

@Pitwheazle
Zeige uns bitte mal den Inhalt deiner gitignore

Den geänderten Code pushe ich normalerweise auf Github und pulle ihn von uberspace aus.

Was spricht dagegen, den Code via ssh hochzuladen? Ich habe selber einen Uber-Asteroid und das ist echt kein Hexenwerk. Fürs Hochladen gibt es auch grafische Oberflächen, falls man die Kommandozeile nicht mag.

Und wenn du eine neue Aufgabenkategorie hast, dann mach doch einfach ein SQL-Dump von dem relevanten Teil und spiele den auf Uber ein. Du musst doch nicht jedes Mal die komplette DB hin und her schieben. Je nachdem, wie dein Datenbank-Design aussieht, werden das ja entweder weitere Einträge mit entsprechender "category"-Spalte sein oder womöglich eine eigene Tabelle, falls jede Kategorie eine andere Datenstruktur hat. Beides ist letztlich ein Hinzufügen von Daten zum bestehenden Bestand. Und was du da in Ansätzen beschreibst, klingt doch recht "unüblich".

[__blackjack__]

@snafu: Da wird ja (normalerweise) auch keine komplette DB hin und her geschoben, denn die ist ja in der gitignore. Nur ist hier anscheinend doch eine lokale Kopie von der DB die im Original auf Uberspace liegt in das Repo gekommen weil "db.sqlite3 aus Uber" nicht ignoriert wurde, entweder weil tatsächlich nur exakt "db.sqlite3" ignoriert wird, oder "*.sqlite3" was natürlich auf den Namen nicht passt wenn man nach der Endung noch mehr an den Namen anhängt.

[snafu]

OK, ich verfolge den Rechentrainer nicht wirklich regelmäßig. Und in Bezug aufs Hochladen wird vermutlich was mit Github Actions gemacht. Dann will ich nichts gesagt haben.

[Pitwheazle]

Was spricht dagegen, den Code via ssh hochzuladen? Ich habe selber einen Uber-Asteroid und das ist echt kein Hexenwerk. Fürs Hochladen gibt es auch grafische Oberflächen, falls man die Kommandozeile nicht mag.

Und wenn du eine neue Aufgabenkategorie hast, dann mach doch einfach ein SQL-Dump von dem relevanten Teil und spiele den auf Uber ein. Du musst doch nicht jedes Mal die komplette DB hin und her schieben.

Nein, ich schiebe keine Datenbank hin und her. Die neue Kategorie besteht aus einem kleinen Datenbankeintrag aber hauptsächlich aus Code in den views. Meine Codeänderung mache ich ja per ssh - aber via github pull.
Ich möchte auch ungern jetzt ein neues Fass aufmachen. Das mit dem pull und push via Github hatte ich ganz gut im Griff.

Die Fehlermeldung ist doch recht eindeutig. Du möchtest eine Datei mit dem Namen "db.sqlite3 aus Uber" in dein Repository pushen. Und die ist zu groß.

OK, das ist die Erklärung -vielen Dank! ... aber leider noch nicht die Lösung. Ich habe mal meine Datein durchsucht und tatsächlich eine Datei "db.sqlite aus uber" gefunden. Zu blöd, die habe ich natürlich selbst so genannt. Mir ist allerdings vollkommen schleierhaft wieso die jetzt in meinem push auftaucht. Zur Erklärung:
Ich habe eine neue Option in meinen Rechentrainer einbauen wollen und da mir das nicht ganz joker war, ob ich da was kaputt mache, habe ich meinen Projektordner kopiert und in einer Kopie gearbeitet. Da hatte ich tatsächlich mit einer Kopie meiner Datenbank aus uber ausprobiert, ob das so, wie gewünscht auch funktioniert. Nachher habe ich diese Datei umbenannt in db.sqlite aus Uber". Das war wohl ein Fehler. Da ich in dieser Kopie aber kein Commit geamcht habe und daher mich auch nicht um gitignore gekümmert habe, habe ich sie dann einfach gelöscht. Nachdem das so wie ich mir das vorgestellt habe, funktioniert hat, habe ich die geänderte view und zwei Templates in meinen original Projektordner eingefügt. Die Datei "db.sqlite3 aus Uber" ist jetzt definitiv nicht in meinem Projektordner drin und war es auch nie - aber anscheinend in meinem git-Ordner. Ich hatte gedacht, ich hätte in etwa verstanden, wie git funktioniert - habe ich aber anscheinend nicht. Wie bekomme ich diese (nicht (mehr) existende) Datei jetzt wieder raus?
Ein Eintrag in gitignore mit:

Code: Alles auswählen

# Django stuff:
db.sqlite3 aus Uber
__pycache__/
*/__pycache__/
*.log
local_settings.py
settings.py
*.sqlite3
*.sqlite3-journal
*.db
*.db-journal
*.sik
*.bak
*.json
*/staticfiles

hilft jedenfalls nicht.

[sparrow]

Du hast die Datei sowohl hinzugefügt als auch ins lokale Repository commited.
Das Löschen nützt nichts. Das ist ja der Sinn von Versionverwaltung, dich genaud davor zu schützen, dass du Dinge löscht.
Keine Ahnung, wie du git bedienst. In der Shell: mit "git restore" die Datei wiederherstellen, mit "git rm" die Datei sowohl lokal als auch aus dem Repository löschen.

[Pitwheazle]

Danke
Die Datei konnte ich ja ganz einfach wiederherstellen. Die ist aber in einem anderen Ordenr und nicht in dem, den ich pushen will. Ich verstehe nicht, wie sie in das git Verzeichnis dieses Ordners kommt ... aber sie ist ja wohl drin. Kann mir jemand sagen, wie ich sie das rausbekomme? Ich bediene git mittels des Terminals ind VisualBasicCode.

[sparrow]

Habe ich doch geschrieben. git rm.

[Sirius3]

Wenn Du einen commit gemacht hast, aber noch nicht gepusht, dann machst Du den letzten commit mit `git reset HEAD~1` wieder rückgängig, löschst die falsche db-Datei und commitest erneut.
Eigentlich sollte eine neue Datei nicht einfach so im Commit landen, die mußt Du aktiv hinzugefügt haben.

[Pitwheazle]

Du hast die Datei sowohl hinzugefügt als auch ins lokale Repository commited.
Das Löschen nützt nichts. Das ist ja der Sinn von Versionverwaltung, dich genaud davor zu schützen, dass du Dinge löscht.
Keine Ahnung, wie du git bedienst. In der Shell: mit "git restore" die Datei wiederherstellen, mit "git rm" die Datei sowohl lokal als auch aus dem Repository löschen.

Nun ja, ich hatte ja geschrieben, dass ich nicht nachvollziehen kann, wie diese Datei in das git Verzeichnis meines Projektordners gekommen ist. Nochmal: Da ich unsicher war, ob das mit einer geplanten Option in meinem Projekt so funktioniert, habe ich von meinem Projektordner eine Kopie gemacht. Diesen Ordner habe ich in VBCode geöffnet und die Änderungen vorgenommen. Unter anderem habe ich hier auch anhand der damals aktuellen Datenbank aus uberspace überprüft, ob alles wie gewünscht funktiont. Später habe ich blöderweise diese Datenbank im Explorer umbenannt in "db.sqlite aus uber". Später habe ich meinen Original-Projektordenr den view und zwei Templates aus dem "Testordner" eingefügt und mit diesem "Originalordner" weitergearbeitet. Wie in diesen die Datei "db.sqlite aus uber" reingekommen sein soll erschließt sich mir nicht. Kann man denn die Dateien in Git irgendwie anzeigen lassen?
Nachtrag: Diese Möglichkeit habe ich gefunden:

Code: Alles auswählen

git ls-tree -r master --name-only

aber, wie erwartet, wird die störende Datei nicht aufgelistet - wo mag sie sein?

Habe ich doch geschrieben. git rm.

"git rm db.sqlite aus uber" funktioniert erwartungsgemäß nicht. Wahrscheinlich wegen der Leerzeichen im Dateinamen oder weil die Datei halt irgenwo im Nirvana ist.

Wenn Du einen commit gemacht hast, aber noch nicht gepusht, dann machst Du den letzten commit mit `git reset HEAD~1` wieder rückgängig, löschst die falsche db-Datei und commitest erneut.
Eigentlich sollte eine neue Datei nicht einfach so im Commit landen, die mußt Du aktiv hinzugefügt haben.

Ich habe ja versucht zu beschreiben, dass ich diesen Vorgang nicht commitet habe, zumindset nicht in meinem aktuellen Ordner. Wie beschrieben hatte ich die besagte Datei im Windowsexplorer hinzugefügt und dort auch später umbenannt.

Aber vielleicht sollte ich alles anders machen. Mit git kann ich sichtlich nicht umgehen. Anfänglich habe ich ja meine Änderungen direkt von meinem Master mittels Filezilla auf uberspace hochgeladen. Da ist es halt etwas schwierig den Überblick zu behalten welche Dateien geändert wurden und hochgeladen werden müssen. Irgendwann habt ihr aber auch erwähnt, dass es andere Möglichkeiten gibt, seine Dateien zu verteilen.

Noch ein Nachtrag:
Ich habe die Datei gefunden mit:

Code: Alles auswählen

git log --pretty=format: --name-only --diff-filter=A  | sort -u

... aber was mache ich jetzt?

[noisefloor]

Hallo,

Mit git kann ich sichtlich nicht umgehen

Na ja, so schlimm ist es ja nicht. Du musst halt konsequent bei git bleiben. Und wenn das was ausprobieren möchtest hat immer _außerhalb_ des Repos und _nicht_ bei Uberspace, sonder komplett separat. Und die Testumgebung halt anschließend _komplett_ löschen und _nichts_ zurück kopieren.

Außerdem: kein Versionskontrollsystem zu nutzen ist bei einem Projekt der Größe IMHO keine Option. Und das gegebene Problem hättest du mit allen anderen Systemen gehabt.

Anfänglich habe ich ja meine Änderungen direkt von meinem Master mittels Filezilla auf uberspace hochgeladen. Da ist es halt etwas schwierig den Überblick zu behalten welche Dateien geändert wurden und hochgeladen werden müssen.

Also wenn ich bei meinem Django-Projekt was hochladen, dann immer alle Dateien. Wo IMHO auch so rein gar nichts gegen spricht. Wir reden ja hier nicht über Giga- oder Terrabyte von Daten...

Gruß, noisefloor

[Pitwheazle]

Und wenn das was ausprobieren möchtest hat immer _außerhalb_ des Repos und _nicht_ bei Uberspace, sonder komplett separat. Und die Testumgebung halt anschließend _komplett_ löschen und _nichts_ zurück kopieren.

Nun, ich dachte das hätte ich auch so gemacht. Uberspace habe ich in meiner Testumgebung nicht genutzt. Aber meinen neuen, funktionierenden Code musste ich ja irgenwie in meinen Originalordner einfügen. Aber die Datei die jetzt Probleme macht habe ich definitiv nicht dort hineinkopiert.

Außerdem: kein Versionskontrollsystem zu nutzen ist bei einem Projekt der Größe IMHO keine Option. Und das gegebene Problem hättest du mit allen anderen Systemen gehabt.
...
Also wenn ich bei meinem Django-Projekt was hochladen, dann immer alle Dateien. Wo IMHO auch so rein gar nichts gegen spricht. Wir reden ja hier nicht über Giga- oder Terrabyte von Daten...

Verstehe ich dich richtig: Ich behalte Git lokal, vergesse Github, da ich da zurzeit meinen Code nicht pushen kann und schicke meine Änderungen mittels Filezilla zu Uberspace?

[Sirius3]

Tolle Strategie, den Kopf in den Sand zu stecken. Ich hatte Dir doch schon geschrieben, dass Du Deine letzten Commits rückgängig machen mußt, damit Du wieder eine saubere Historie hast.
Git ist ja gerade dafür da, einen einheitlichen Stand der Dateien über mehrere Umgebungen hinweg sicher zu stellen. Man kopiert also nichts händisch. Wenn Du einen neuen Code entwickelst, dann erstellst Du normalerweise einen neuen Branch, in dem Du die Änderungen so lange pflegst, bist es soweit fertig ist, dass Du die Änderungen im Main-Branch veröffentlichen willst.
Wenn Dir die Kommandozeile zu mühselig ist, dann nimm halt ein graphisches Tool für Git oder gleich ein passendes VSCode-Plugin.

[Pitwheazle]

Normalerweise versuche ich schon mit Branches zu arbeiten und diese zu Mergen, wenn alles klappt, Manchmal finde ich aber hinterher noch was, was nicht so ganz stimmt während ich an einem anderen Problem weitergearbeitet habe, da habe ich möglicherweise nicht klar genug getrennt. Da ich aber meinen Code für das "Duell Light" zunächst mit meiner kleinen lokalen Datebnak mit Testaccounts entwickelt habe und dann mit den Daten aus Uber ausprobieren wollte, habe ich die Datenbanken ausgetauscht - das habe ich händisch gemacht. Geht das auch anders?
Ich wollte auch nur solange den Kopf in den Sand stecken bis, ich diese blöde Datei aus meinem Repository rausbeckommen habe und hier war dein letzter Tipp schon mal ein Anfang:
Ich habe git Graph runtergeladen und den Störenfried gefunden und dort auch den Eintrag zu "db.sqlight3 aus Uber". Bei dem wird allerdings "unable to View Diff * Deleted" angezeigt.
Ich wüsste jetzt also zumindest bis zu welchem Commit ich alles Rückgängig machen müsste - oder? Mittendrin den Commit zu löschen geht ja wohl nicht. Muss ich dazu jetzt alle späteren Änderungen raussuchen und zwischenspeichern und dann wieder einfügen?
Ich hänge hier mal einen Screenshot an:

[Pitwheazle]

Doch nicht. Rot bedeutet gelöscht, Zwei Commits vorher habe ich diese Datei wohl eingefügt, bzw blöd umbenannt:

[noisefloor]

Hallo,

Aber die Datei die jetzt Probleme macht habe ich definitiv nicht dort hineinkopiert.

Na ja, die Datei kommt ja nicht aus dem Nichts... und wenn du es nicht warst, dann war es halt wer anders. Kannst ja mal überlegen, wer noch Zugriff dorthin hat.

Verstehe ich dich richtig: Ich behalte Git lokal, vergesse Github, da ich da zurzeit meinen Code nicht pushen kann und schicke meine Änderungen mittels Filezilla zu Uberspace?

Jein. Github hat damit in erster Instanz nichts zu tun. Was ich meinte: ich sehe kein Problem darin, immer alle Dateien auf dem aktuellen, stabilen Master aus dem Repo via Filezilla zu Uberspace zu kopieren. Das ist auf jeden Fall deutlich weniger fehleranfällig, als selektiv Dateien zu kopieren und sich zu merken, was am kopieren muss bzw. kopieren muss.

Wenn Dir die Kommandozeile zu mühselig ist, dann nimm halt ein graphisches Tool für Git

Ich habe für PyTuDe die Windows Desktop Anwendung von Github genommen. Die ist ganz komfortable und spielt sehr gut mit GitHub zusammen.

Gruß, noisefloor

[Pitwheazle]

Aber die Datei die jetzt Probleme macht habe ich definitiv nicht dort hineinkopiert.

Na ja, die Datei kommt ja nicht aus dem Nichts...