Konwertuję wszystko na Git na własny użytek i znalazłem kilka starych wersji pliku już w repozytorium. Jak zapisać historię w prawidłowej kolejności zgodnie z „datą modyfikacji” pliku, aby mieć dokładną historię pliku?

Powiedziano mi, że coś takiego działa:

git filter-branch --env-filter="GIT_AUTHOR_DATE=... --index-filter "git commit path/to/file --date " --tag-name-filter cat -- --all  

Porada, którą otrzymałeś, jest wadliwa. Bezwarunkowe ustawienie GIT_AUTHOR_DATE w --env-filterspowoduje przepisanie daty każdego zatwierdzenia. Poza tym użycie git commit w środku byłoby niezwykłe --index-filter.

Masz tutaj do czynienia z wieloma niezależnymi problemami.

Określanie dat innych niż „teraz”

Każde zatwierdzenie ma dwie daty: datę autora i datę osoby zatwierdzającej. Możesz zastąpić każdą z nich, podając wartości za pomocą zmiennych środowiskowych GIT_AUTHOR_DATE i GIT_COMMITTER_DATE dla każdego polecenia, które zapisuje nowe zatwierdzenie. Zobacz „Formaty daty” w git-commit (1) lub poniżej:

Git internal format = <unix timestamp> <time zone offset>, e.g.  1112926393 +0200
RFC 2822            = e.g. Thu, 07 Apr 2005 22:13:13 +0200
ISO 8601            = e.g. 2005-04-07T22:13:13

Jedynym poleceniem, które zapisuje nowe zatwierdzenie podczas normalnego użytkowania, jest polecenie git . Posiada również --dateopcję, która pozwala bezpośrednio określić datę autora. Twoje przewidywane użycie obejmuje git filter-branch --env-filterrównież wykorzystanie wyżej wymienionych zmiennych środowiskowych (są one częścią „env”, po której nazwa jest nazwana; patrz „Opcje” w git-filter-branch (1) i leżące u jej podstaw polecenie „hydrauliczne” git-commit -drzewo (1) .

Wstawianie pliku do historii pojedynczego odwołania

Jeśli twoje repozytorium jest bardzo proste (tzn. Masz tylko jedną gałąź, bez tagów), prawdopodobnie możesz użyć git rebase do wykonania tej pracy.

W poniższych poleceniach użyj nazwy obiektu (skrót SHA-1) zatwierdzenia zamiast „A”. Nie zapomnij użyć jednej z metod „przesłonięcia daty” podczas uruchamiania git commit .

---A---B---C---o---o---o   master

git checkout master
git checkout A~0
git add path/to/file
git commit --date='whenever'
git tag ,new-commit -m'delete me later'
git checkout -
git rebase --onto ,new-commit A
git tag -d ,new-commit

---A---N                      (was ",new-commit", but we delete the tag)
        \
         B'---C'---o---o---o   master

Jeśli chcesz zaktualizować A, aby zawierał nowy plik (zamiast tworzenia nowego zatwierdzenia w miejscu, w którym został dodany), użyj git commit --amendzamiast git commit. Wynik wyglądałby następująco:

---A'---B'---C'---o---o---o   master

Powyższe działa tak długo, jak można nazwać zatwierdzenie, które powinno być rodzicem nowego zatwierdzenia. Jeśli naprawdę chcesz, aby nowy plik został dodany za pomocą nowego zatwierdzenia głównego (bez rodziców), potrzebujesz czegoś innego:

B---C---o---o---o   master

git checkout master
git checkout --orphan new-root
git rm -rf .
git add path/to/file
GIT_AUTHOR_DATE='whenever' git commit
git checkout -
git rebase --root --onto new-root
git branch -d new-root

N                       (was new-root, but we deleted it)
 \
  B'---C'---o---o---o   master

git checkout --orphanjest stosunkowo nowy (Git 1.7.2), ale istnieją inne sposoby robienia tego samego, co działa na starszych wersjach Gita.

Wstawianie pliku do historii wielu referencji

Jeśli twoje repozytorium jest bardziej złożone (tzn. Ma więcej niż jeden odnośnik (gałęzie, tagi itp.)), Prawdopodobnie będziesz musiał użyć git filter-branch . Przed użyciem git filter-branch powinieneś wykonać kopię zapasową całego repozytorium. Wystarczy proste archiwum tar całego działającego drzewa (w tym katalogu .git). git filter-branch wykonuje kopie zapasowe kopii zapasowej, ale często łatwiej jest odzyskać dane po niezupełnie właściwym filtrowaniu, po prostu usuwając .gitkatalog i przywracając go z kopii zapasowej.

Uwaga: Poniższe przykłady używają polecenia niższego poziomu git update-index --addzamiast git add. Możesz użyć git add , ale najpierw musisz skopiować plik z jakiejś lokalizacji zewnętrznej do oczekiwanej ścieżki ( --index-filteruruchamia polecenie w tymczasowym drzewie GIT_WORK_TREE, które jest puste).

Jeśli chcesz, aby nowy plik był dodawany do każdego istniejącego zatwierdzenia, możesz to zrobić:

new_file=$(git hash-object -w path/to/file)
git filter-branch \
  --index-filter \
    'git update-index --add --cacheinfo 100644 '"$new_file"' path/to/file' \
  --tag-name-filter cat \
  -- --all
git reset --hard

Naprawdę nie widzę powodu, by zmieniać daty istniejących zatwierdzeń --env-filter 'GIT_AUTHOR_DATE=…'. Gdybyś go użył, uczyniłbyś to warunkowym, aby przepisał datę każdego zatwierdzenia.

Jeśli chcesz, aby nowy plik pojawiał się tylko w zatwierdzeniach po pewnym istniejącym zatwierdzeniu („A”), możesz to zrobić:

file_path=path/to/file
before_commit=$(git rev-parse --verify A)
file_blob=$(git hash-object -w "$file_path")
git filter-branch \
  --index-filter '

    if x=$(git rev-list -1 "$GIT_COMMIT" --not '"$before_commit"') &&
       test -n "$x"; then
         git update-index --add --cacheinfo 100644 '"$file_blob $file_path"'
    fi

  ' \
  --tag-name-filter cat \
  -- --all
git reset --hard

Jeśli chcesz, aby plik został dodany za pomocą nowego zatwierdzenia, które ma być wstawione w środku twojej historii, musisz wygenerować nowy zatwierdzenie przed użyciem git filter-branch i dodać --parent-filterdo git filter-branch :

file_path=path/to/file
before_commit=$(git rev-parse --verify A)

git checkout master
git checkout "$before_commit"
git add "$file_path"
git commit --date='whenever'
new_commit=$(git rev-parse --verify HEAD)
file_blob=$(git rev-parse --verify HEAD:"$file_path")
git checkout -

git filter-branch \
  --parent-filter "sed -e s/$before_commit/$new_commit/g" \
  --index-filter '

    if x=$(git rev-list -1 "$GIT_COMMIT" --not '"$new_commit"') &&
       test -n "$x"; then
         git update-index --add --cacheinfo 100644 '"$file_blob $file_path"'
    fi

  ' \
  --tag-name-filter cat \
  -- --all
git reset --hard

Możesz również zaaranżować, aby plik był dodawany po raz pierwszy w nowym głównym zatwierdzeniu: utwórz nowy główny zatwierdzenie za pomocą metody „osieroconej” z sekcji git rebase (przechwyć new_commit), użyj bezwarunkowego --index-filteri --parent-filterpodobnego "sed -e \"s/^$/-p $new_commit/\"".

Możesz utworzyć zatwierdzenie jak zwykle, ale kiedy zatwierdzasz, ustaw zmienne środowiskowe GIT_AUTHOR_DATEi GIT_COMMITTER_DATEodpowiednie czasy danych.

Oczywiście spowoduje to zatwierdzenie na końcu gałęzi (tj. Przed bieżącym zatwierdzeniem HEAD). Jeśli chcesz odsunąć go z powrotem w repozytorium, musisz się trochę rozkoszować. Powiedzmy, że masz tę historię:

o--o--o--o--o

I chcesz, aby twoje nowe zatwierdzenie (oznaczone jako „X”) pojawiło się na drugim miejscu :

o--X--o--o--o--o

Najłatwiejszym sposobem jest rozgałęzienie od pierwszego zatwierdzenia, dodanie nowego zatwierdzenia, a następnie zmiana bazy wszystkich innych zatwierdzeń na nowym. Tak jak:

$ git checkout -b new_commit $desired_parent_of_new_commit
$ git add new_file
$ GIT_AUTHOR_DATE='your date' GIT_COMMITTER_DATE='your date' git commit -m 'new (old) files'
$ git checkout master
$ git rebase new_commit
$ git branch -d new_commit

Wiem, że to pytanie jest dość stare, ale to właśnie dla mnie zadziałało:

git commit --date="10 day ago" -m "Your commit message" 

W moim przypadku w czasie I uratował kilka wersji myfile jak myfile_bak, myfile_old, myfile_2010, tworzenie kopii zapasowych / myfile itp chciałem umieścić historię myfile w git przy użyciu ich daty modyfikacji. Więc zmień nazwę najstarszego na myfile, git add myfilea następnie git commit --date=(modification date from ls -l) myfilezmień nazwę następnego najstarszego na myfile, kolejne polecenie git z opcją --data, powtórz ...

Aby to nieco zautomatyzować, możesz użyć shell-foo, aby uzyskać czas modyfikacji pliku. Zacząłem od ls -li cut, ale stat (1) jest bardziej bezpośredni

git commit --date = "` stat -c% y mój_plik `" mój_plik

Oto co mogę użyć, aby dokonać zmian na foodo N=1dni w przeszłości:

git add foo
git commit -m "Update foo"
git commit --amend --date="$(date -v-1d)"

Jeśli chcesz, aby zobowiązać się do jeszcze starszej daty, powiedzmy 3 dni z powrotem, wystarczy zmienić dateargumentu date -v-3d.

Jest to bardzo przydatne, gdy na przykład zapomnisz coś popełnić.

AKTUALIZACJA : --dateakceptuje również wyrażenia takie jak --date "3 days ago"lub nawet --date "yesterday". Możemy więc zredukować to do jednego wiersza polecenia:

git add foo ; git commit --date "yesterday" -m "Update"

W moim przypadku podczas korzystania z opcji --date mój proces git się zawiesił. Być może zrobiłem coś strasznego. W rezultacie pojawił się plik index.lock. Więc ręcznie usunąłem pliki .lock z folderu .git i wykonałem, aby wszystkie zmodyfikowane pliki zostały zatwierdzone w minionych terminach i tym razem zadziałało. Dzięki za wszystkie odpowiedzi tutaj.

git commit --date="`date --date='2 day ago'`" -am "update"

Aby dokonać zatwierdzenia, które wygląda tak, jakby było zrobione w przeszłości, musisz ustawić oba GIT_AUTHOR_DATEi GIT_COMMITTER_DATE:

GIT_AUTHOR_DATE=$(date -d'...') GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE" git commit -m '...'

gdzie date -d'...'może być dokładna data jak 2019-01-01 12:00:00lub względna jak 5 months ago 24 days ago.

Aby zobaczyć obie daty w dzienniku git, użyj:

git log --pretty=fuller

Działa to również w przypadku zatwierdzeń scalania:

GIT_AUTHOR_DATE=$(date -d'...') GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE" git merge <branchname> --no-ff

Zawsze możesz zmienić datę na komputerze, dokonać zatwierdzenia, a następnie zmienić datę z powrotem i przesłać.

Lub po prostu użyj fałszywej historii git, aby wygenerować ją dla określonego zakresu danych.