3. SOLVED: Git: Große Datei aus Repository(-History) entfernen

SOLVED: Git: Große Datei aus Repository(-History) entfernen

  • M

    Hallo,

    folgende Situation, ein Git Repository dass von mehreren Personen benutzt wird enthält seit dem letzten Commit eine sehr große Datei. Bei jedem neuen Clone
    dieses Repositories muss der Server nun diese Datei vorhalten.

    Wie entferne ich diese Datei nun wieder aus dem Repository ohne ein neues
    erstellen zu müssen.

    Zur Klarstellung:
    Das Problem ist, dass wenn sich jemand das Repo ganz neu cloned, er ja die
    gesamte "History" vom Server mit erhält, diese ist jedoch durch die Datei
    zu groß.

    Danke schonmal 🙂

    0
  • M

    Ok hab es selber gelöst bekommen.

    Ein git reset auf den Commit, und anschließend ein git push --mirror -f.

    0
  • ?

    Im allgemeinen Fall mit git filter-branch (wenn man nicht gerade den letzten commit bearbeiten will).

    0
  • N

    Mario Sandler schrieb:

    Wie entferne ich diese Datei nun wieder aus dem Repository ohne ein neues erstellen zu müssen.

    Ungefähr so:
    http://help.github.com/removing-sensitive-data/

    Wobei Deine Kollegen das Repo neu klonen sollten.

    0
  • N

    Mario Sandler schrieb:

    Ein git reset auf den Commit, und anschließend ein git push --mirror -f.

    Wenn Du auch die Repogröße wieder runterbekommen möchtest, dann schau Dir auch die verlinkten git-gc-Aufrufe etc. an.

    git-filter-branch ist zwar sehr mächtig, aber wenn man nur einen einzelnen Commit bearbeiten möchte, ist oft sowas bequemer:

    git checkout -b reparaturbranch $SHA_DES_KAPUTTEN_COMMITS
git rm falsches-file.flasch
git commit --amend
git checkout master
git rebase reparaturbranch
git push -f

    Wobei man sich in all diesen Fällen natürlich bewusst sein muss, dass man damit Kollegen das Repo unter den Füßen wegschießt, dh. das muss man auf alle Fälle absprechen und gut koordinieren.

    0
  • C

    --mirror bei git push ist aber nicht so gut in diesem Fall. Das pusht nämlich wirklich alle refs auf den Server, was dazu führt, dass das Repository auf dem Server plötzlich remote tracking branches besitzt, die dort gar nicht hingehören. Ich würde das Server-Repository mal prüfen und alle überflüssige remote-Branches löschen.

    Was ich meine ist folgendes.

    /tmp$ mkdir a && cd a/ && git init
Initialized empty Git repository in /tmp/a/.git/
a$ echo x > foo
a$ git add foo
a$ git commit -m foo
[master (root-commit) a94bdc0] foo
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 foo
a$

    Ein neues Repository angelegt in /tmp/a. Jetzt clone ich das:

    a$ cd .. && git clone a b && cd b
Initialized empty Git repository in /tmp/b/.git/
b$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
b$ cd ../a
a$ git branch -a
* master
a$

    Der tracking branch remotes/origin/master ist im Repository b sichtbar, aber nicht auf dem Server-Repository a. Jetzt ein git push mit --mirror:

    a$ cd ../b
b$ git push --mirror
Total 0 (delta 0), reused 0 (delta 0)
To /tmp/a
 * [new branch]      origin/HEAD -> origin/HEAD
 * [new branch]      origin/master -> origin/master
b$

    Man sieht schon, da werden branches gepusht, obwohl das Repository b ein frischer Clone von a war.

    b$ cd ../a
a$ git branch -a
* master
  remotes/origin/HEAD
  remotes/origin/master
a$

    Das bestätigt den Verdacht. Das Server-Repository a hat jetzt plötzlich remote-Branches bekommen, die dort nicht hingehören.

    0
  • R

    Da das Problem ja bereits gelöst ist, mache ich mal eine kleine OT-Anmerkung. Wenn man große Dateien mit git verwalten möchte (zB Musiksammlung oä.), dann kann man dies zB mit git-annex machen.

    0
Log in to reply