Come rimuovo la vecchia cronologia da un repository git?

Temo di non riuscire a trovare qualcosa di simile a questo particolare scenario.

Ho un repository git con molta storia: 500+ rami, 500+ tag, che risale alla metà del 2007. Contiene ~ 19.500 commit. Vorremmo rimuovere tutta la cronologia prima del 1 ° gennaio 2010, per renderla più piccola e più semplice da gestire (conserveremmo una copia completa della cronologia in un repository di archivi).

Conosco il commit che voglio essere diventato la radice del nuovo repository. Non riesco, tuttavia, a capire il git mojo corretto per troncare il repository per iniziare con quel commit. Sto indovinando una variante di

git filter-branch

coinvolgere innesti sarebbe necessario; potrebbe anche essere necessario per il trattamento di ciascuna delle oltre 200 filiali che vogliamo tenere separatamente e poi ricucire il repo di nuovo insieme (cosa che non so come fare).

Qualcuno ha mai fatto qualcosa del genere? Ho git 1.7.2.3 se questo è importante.

Basta creare un innesto del genitore del nuovo commit root su nessun genitore (o su un commit vuoto, ad esempio il commit root reale del proprio repository). Per esempioecho "<NEW-ROOT-SHA1>" > .git/info/grafts

Dopo aver creato l'innesto, ha subito effetto; dovresti essere in grado di guardare git loge vedere che i vecchi commit indesiderati sono andati via:

$ echo 4a46bc886318679d8b15e05aea40b83ff6c3bd47 > .git/info/grafts
$ git log --decorate | tail --lines=11
commit cb3da2d4d8c3378919844b29e815bfd5fdc0210c
Author: Your Name <your.email@example.com>
Date:   Fri May 24 14:04:10 2013 +0200

    Another message

commit 4a46bc886318679d8b15e05aea40b83ff6c3bd47 (grafted)
Author: Your Name <your.email@example.com>
Date:   Thu May 23 22:27:48 2013 +0200

    Some message

Se tutto sembra come previsto, puoi semplicemente fare un semplice git filter-branch -- --allper renderlo permanente.

ATTENZIONE: dopo aver eseguito il passaggio della diramazione del filtro , tutti gli ID di commit saranno cambiati, quindi chiunque utilizzi il vecchio repository non deve mai fondersi con nessuno che utilizza il nuovo repository.

Forse è troppo tardi per pubblicare una risposta, ma poiché questa pagina è il primo risultato di Google, potrebbe essere comunque utile.

Se vuoi liberare spazio nel tuo repository git, ma non vuoi ricostruire tutti i tuoi commit (rebase o innesto), ed essere ancora in grado di spingere / tirare / unire da persone che hanno il repository completo, puoi usare git clone shallow clone ( parametro --depth ).

; Clone the original repo into limitedRepo
git clone file:///path_to/originalRepo limitedRepo --depth=10

; Remove the original repo, to free up some space
rm -rf originalRepo
cd limitedRepo
git remote rm origin

Potresti riuscire a rendere superficiale il tuo repository esistente seguendo questi passaggi:

; Shallow to last 5 commits
git rev-parse HEAD~5 > .git/shallow

; Manually remove all other branches, tags and remotes that refers to old commits

; Prune unreachable objects
git fsck --unreachable ; Will show you the list of what will be deleted
git gc --prune=now     ; Will actually delete your data

Come rimuovere tutti i tag git local?

Ps: le versioni precedenti di git non supportavano clone / push / pull da / a repository superficiali.

Questo metodo è facile da capire e funziona bene. L'argomento per lo script ( $1) è un riferimento (tag, hash, ...) al commit a partire dal quale si desidera conservare la cronologia.

#!/bin/bash
git checkout --orphan temp $1 # create a new branch without parent history
git commit -m "Truncated history" # create a first commit on this branch
git rebase --onto temp $1 master # now rebase the part of master branch that we want to keep onto this branch
git branch -D temp # delete the temp branch

# The following 2 commands are optional - they keep your git repo in good shape.
git prune --progress # delete all the objects w/o references
git gc --aggressive # aggressively collect garbage; may take a lot of time on large repos

NOTA che i vecchi tag rimarranno comunque presenti; quindi potrebbe essere necessario rimuoverli manualmente

osservazione: so che è quasi la stessa risposta di @yoyodin, ma qui ci sono alcuni comandi e informazioni importanti importanti. Ho provato a modificare la risposta, ma poiché si tratta di una modifica sostanziale alla risposta di @ yoyodin, la mia modifica è stata respinta, quindi ecco le informazioni!

Prova questo metodo Come troncare la cronologia di git :

#!/bin/bash
git checkout --orphan temp $1
git commit -m "Truncated history"
git rebase --onto temp $1 master
git branch -D temp

Ecco $1SHA-1 del commit che si desidera mantenere e lo script creerà un nuovo ramo che contiene tutti i commit tra $1e masterviene eliminata tutta la cronologia precedente. Si noti che questo semplice script presuppone che non si abbia un ramo esistente chiamato temp. Si noti inoltre che questo script non cancella i dati git per la cronologia precedente. Corri git gc --prune=all && git repack -a -f -F -ddopo aver verificato che vuoi davvero perdere tutta la storia. Potresti anche aver bisogno, rebase --preserve-mergesma ti avverto che l'implementazione git di quella funzione non è perfetta. Ispeziona i risultati manualmente se lo usi.

In alternativa alla riscrittura della storia, considera l'utilizzo git replacecome in questo articolo del libro Pro Git . L'esempio discusso riguarda la sostituzione di un commit parent per simulare l'inizio di un albero, mantenendo comunque la cronologia completa come ramo separato per la custodia.

Se si desidera mantenere il repository upstream con cronologia completa , ma checkout locali più piccoli, eseguire un clone superficiale con git clone --depth=1 [repo].

Dopo aver inviato un commit, puoi farlo

1. git fetch --depth=1per potare i vecchi impegni. Questo rende irraggiungibili i vecchi commit e i loro oggetti.
2. git reflog expire --expire-unreachable=now --all. Per far scadere tutti i vecchi commit e i loro oggetti
3. git gc --aggressive --prune=all per rimuovere i vecchi oggetti

Vedi anche Come rimuovere la cronologia git locale dopo un commit? .

Si noti che non è possibile trasferire questo repository "shallow" in un'altra posizione: "aggiornamento shallow non consentito". Vedi Rifiuto remoto (aggiornamento superficiale non consentito) dopo aver modificato l'URL remoto Git . Se vuoi farlo, devi rimanere con l'innesto.

Avevo bisogno di leggere diverse risposte e alcune altre informazioni per capire cosa stavo facendo.

1. Ignora tutto ciò che è più vecchio di un certo commit

Il file .git/info/graftspuò definire genitori falsi per un commit. Una riga con solo un ID commit indica che il commit non ha un genitore. Se volessimo dire che ci preoccupiamo solo degli ultimi 2000 commit, possiamo digitare:

git rev-parse HEAD~2000 > .git/info/grafts

git rev-parse ci fornisce l'id di commit del 2000 ° genitore del commit corrente. Il comando sopra sovrascriverà il file innesto, se presente. Controlla se c'è prima.

2. Riscrivi la cronologia di Git (opzionale)

Se vuoi rendere reale questo genitore falso innestato, esegui:

git filter-branch -- --all

Cambierà tutti gli ID di commit. Ogni copia di questo repository deve essere aggiornata forzatamente.

3. Pulire lo spazio su disco

Non ho fatto il passaggio 2, perché volevo che la mia copia fosse compatibile con l'upstream. Volevo solo risparmiare un po 'di spazio su disco. Per dimenticare tutti i vecchi impegni:

git prune
git gc

Alternativa: copie superficiali

Se si dispone di una copia superficiale di un altro repository e si desidera solo risparmiare spazio su disco, è possibile eseguire l'aggiornamento .git/shallow. Ma fai attenzione che nulla punta a un commit di prima. Quindi potresti eseguire qualcosa del genere:

git fetch --prune
git rev-parse HEAD~2000 > .git/shallow
git prune
git gc

L'entrata in shallow funziona come un innesto. Ma fai attenzione a non usare innesti e shallow allo stesso tempo. Almeno, non ci sono le stesse voci, fallirà.

Se hai ancora dei vecchi riferimenti (tag, rami, testine remote) che indicano commit precedenti, non verranno ripuliti e non risparmierai più spazio sul disco.

Quando rebase o spingi verso head / master questo errore può verificarsi

remote: GitLab: You are not allowed to access some of the refs!
To git@giturl:main/xyz.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@giturl:main/xyz.git'

Per risolvere questo problema nella dashboard di Git è necessario rimuovere il ramo principale da "Rami protetti"

allora puoi eseguire questo comando

git push -f origin master

o

git rebase --onto temp $1 master

Ci sono troppe risposte che non sono attuali e alcune non spiegano completamente le conseguenze. Ecco cosa ha funzionato per me nel tagliare la storia usando l'ultimo git 2.26:

Per prima cosa crea un commit fittizio. Questo commit verrà visualizzato come primo commit nel repository troncato. Ne hai bisogno perché questo commit conterrà tutti i file di base per la cronologia che stai conservando. SHA è l'ID del commit precedente del commit che si desidera conservare (in questo esempio 8365366). La stringa "Iniziale" verrà visualizzata come messaggio di commit del primo commit. Se si utilizza Windows, digitare il comando seguente dal prompt dei comandi di Git Bash.

# 8365366 is id of parent commit after which you want to preserve history
echo 'Initial' | git commit-tree 8365366^{tree}

Sopra il comando stamperà SHA, ad esempio d10f7503bc1ec9d367da15b540887730db862023.

Ora basta digitare:

# d10f750 is commit ID from previous command
git rebase --onto d10f750 8365366

Questo prima metterà tutti i file al momento del commit 8365366nel commit fittizio d10f750. Quindi riprodurrà tutti i commit dopo 8365366 sopra d10f750. Infine master, il puntatore della diramazione verrà aggiornato per l'ultimo commit riprodotto.

Ora se vuoi spingere questi repository troncati, fallo e basta git push -f.

Poche cose da tenere a mente (si applicano ad altri metodi oltre a questo): i tag non vengono trasferiti. Mentre gli ID di commit e i timestamp vengono conservati, vedrai GitHub mostrare questi commit nell'intestazione di grumi come Commits on XY date.

Fortunatamente è possibile mantenere la cronologia troncata come "archivio" e successivamente è possibile unire nuovamente i repository ritagliati con i repository di archivio. Per fare ciò, consulta questa guida .

è possibile eliminare la directory, i file e anche l'intera cronologia relativa alla directory o al file utilizzando il jar di seguito [download] e i comandi

file bfg.jar: https://rtyley.github.io/bfg-repo-cleaner/

git clone --bare repo-url cd repo_dir java -jar bfg.jar --delete-cartelle nome_cartella git reflog scadono --expire = now --all && git gc --prune = now --aggressive git push --mirror repo_url

1. rimuovere i dati git, rm .git
2. git init
3. aggiungi un telecomando git
4. forza di spinta