Попробуйте использовать .live()
вместо .bind()
; .live()
свяжет .hover
с вашим флажком после выполнения запроса Ajax.
Используйте BFG Repo-Cleaner , более быструю и быструю альтернативу git-filter-branch
, специально разработанную для удаления нежелательных файлов из истории Git.
Аккуратно следуйте за использованием команды , основная часть - это:
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git
Любые файлы размером более 100 МБ (которые не входят в ваш последний коммит ) будут удалены из вашей истории хранилища Git. Затем вы можете использовать git gc
для очистки мертвых данных:
$ git gc --prune=now --aggressive
BFG обычно не менее 10-50x быстрее, чем работает git-filter-branch
, и, как правило, для использования.
Полное раскрытие: я являюсь автором BFG Repo-Cleaner.
git filter-branch --tree-filter 'rm -f path/to/file' HEAD
работал очень хорошо для меня, хотя я столкнулся с той же проблемой, что описал здесь здесь , которую я решил, выполнив это предложение .
В книге pro-git есть целая глава в истории перезаписи - посмотрите раздел filter-branch
/ Удаление файла из раздела Every Commit .
-f
(или --force
) к вашей команде git push
: «Обычно команда отказывается обновлять удаленный реф, который не является предком локального ref, используемого для его перезаписывания. Этот флаг отключает проверку. Это может привести к тому, что удаленный репозиторий потеряет фиксации; используйте его с осторожностью ».
– Greg Bacon
5 February 2013 в 01:47
... "git rm --cached -rf --ignore-unmatch path/to/dir"...
– rynop
20 August 2014 в 17:08
Я в основном сделал то, что было в этом ответе: https://stackoverflow.com/a/11032521/1286423
(для истории я скопирую его здесь)
$ git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch YOURFILENAME" HEAD
$ rm -rf .git/refs/original/
$ git reflog expire --all
$ git gc --aggressive --prune
$ git push origin master --force
Это не сработало, потому что мне очень нравится переименовывать и перемещать вещи. Поэтому некоторые большие файлы были в папках, которые были переименованы, и я думаю, что gc не смог удалить ссылку на эти файлы из-за ссылки в tree
объектах, указывающих на эти файлы. Моим окончательным решением действительно убить это было:
# First, apply what's in the answer linked in the front
# and before doing the gc --prune --aggressive, do:
# Go back at the origin of the repository
git checkout -b newinit <sha1 of first commit>
# Create a parallel initial commit
git commit --amend
# go back on the master branch that has big file
# still referenced in history, even though
# we thought we removed them.
git checkout master
# rebase on the newinit created earlier. By reapply patches,
# it will really forget about the references to hidden big files.
git rebase newinit
# Do the previous part (checkout + rebase) for each branch
# still connected to the original initial commit,
# so we remove all the references.
# Remove the .git/logs folder, also containing references
# to commits that could make git gc not remove them.
rm -rf .git/logs/
# Then you can do a garbage collection,
# and the hidden files really will get gc'ed
git gc --prune --aggressive
Мое репо (.git
) изменилось с 32 МБ на 388 КБ, что даже ветвь фильтра не могла очистить.
Вы можете сделать это, используя команду branch filter
:
git filter-branch --tree-filter 'rm -rf path/to/your/file' HEAD
Попробовав практически каждый ответ в SO, я наконец нашел этот камень, который быстро удалил и удалил большие файлы в моем репозитории и разрешил мне снова синхронизировать: http://www.zyxware.com/articles/4027 / how-to-delete-files-постоянно-from-your-local-and-remote-git-repositories
CD в локальную рабочую папку и выполните следующую команду:
git filter-branch -f --index-filter "git rm -rf --cached --ignore-unmatch FOLDERNAME" -- --all
заменить FOLDERNAME файлом или папкой, которую вы хотите удалить из данного репозитория git.
После этого выполните следующие команды для очистки локального репозитория:
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now
Теперь нажмите все изменения в удаленном репозитории:
git push --all --force
Это очистит удаленный репозиторий.
Эти команды работали в моем случае:
git filter-branch --force --index-filter 'git rm --cached -r --ignore-unmatch oops.iso' --prune-empty --tag-name-filter cat -- --all
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now
Это немного отличается от указанных выше версий.
Для тех, кому нужно нажать это на github / bitbucket (только я испытал это с битбакетом):
# WARNING!!!
# this will rewrite completely your bitbucket refs
# will delete all branches that you didn't have in your local
git push --all --prune --force
# Once you pushed, all your teammates need to clone repository again
# git pull will not work
git rm --cached files
. Предложение Грега Бэкона более полно и совершенно одинаково для этой шахты, но он пропустил индекс -force для случаев, когда вы используете фильтр-ветвь в течение нескольких раз, и он написал так много информации, что моя версия похожа на резюме из этого.
– Kostanos
14 June 2013 в 15:09
-f
не только -rf
здесь git rm --cached -rf --ignore-unmatch oops.iso
, а git rm --cached -r --ignore-unmatch oops.iso
в соответствии с @ lfender6445 ниже
– drstevok
21 October 2016 в 06:18
Я столкнулся с этим с учетной записью bitbucket, где я случайно сохранил ginormous * .jpa резервные копии моего сайта.
git filter-branch --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch MY-BIG-DIRECTORY-OR-FILE' --tag-name-filter cat -- --all
Переместить MY-BIG-DIRECTORY
с соответствующей папкой, чтобы полностью переписать вашу историю (, включая теги ).
: http://naleid.com/blog/2012/01/17/finding-and-purging-big-files-from-git-history
Когда вы столкнетесь с этой проблемой, git rm
не будет достаточным, так как git помнит, что файл существовал один раз в нашей истории и, следовательно, будет ссылаться на него.
Чтобы все ухудшилось, перезагрузка тоже нелегкая, потому что любые ссылки на blob предотвратят сборщик мусора git от очистки пространства. Это включает в себя удаленные ссылки и ссылки reflog.
Я собрал git forget-blob
, маленький скрипт, который пытается удалить все эти ссылки, а затем использует git filter-branch для перезаписи каждой фиксации в ветке.
Как только ваш blob полностью не найден, git gc
избавится от него
. Использование довольно просто git forget-blob file-to-forget
. Вы можете получить дополнительную информацию здесь
Я собрал это вместе благодаря ответам из Stack Overflow и некоторым блогам. Кредиты к ним!
Используйте Git Extensions , это инструмент пользовательского интерфейса.
Не используйте «git filter-branch» перед использованием этого инструмента, так как он не будет использоваться для добавления файлов в хранилищах в файлах хранилища в репозиториях. способный находить файлы, удаленные с помощью «filter-branch» (Altough «filter-branch» не полностью удаляет файлы из файлов пакета репозитория).
Просто обратите внимание, что эти команды могут быть очень разрушительными. Если на репо будет работать больше людей, все они должны будут вытащить новое дерево. Три средних команды не нужны, если ваша цель НЕ уменьшить размер. Поскольку ветвь фильтра создает резервную копию удаленного файла и может оставаться там в течение длительного времени.
$ git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch YOURFILENAME" HEAD
$ rm -rf .git/refs/original/
$ git reflog expire --all
$ git gc --aggressive --prune
$ git push origin master --force
git filter-branch --force --index-filter 'git rm --cached -r --ignore-unmatch oops.iso' --prune-empty --tag-name-filter cat -- --all
вместо первой из вашего кода
– Kostanos
14 June 2013 в 03:31
Если вы знаете, что ваша фиксация была последней, а не через все дерево, сделайте следующее:
git filter-branch --tree-filter 'rm LARGE_FILE.zip' HEAD~10..HEAD
(Лучший ответ, который я видел в этой проблеме: https://stackoverflow.com/a/42544963/714112 , скопирован здесь, так как этот поток выглядит высоко в ранжировании поиска Google, но это другой нет)
--tag-name-filter cat
для повторной маркировки новых соответствующих коммитов по мере их перезаписи, т. Е. git filter-branch --index-filter 'git rm --cached --ignore-unmatch a b' --tag-name-filter cat HEAD
(см. этот связанный ответ )
– naitsirhc
8 February 2018 в 04:25
git filter-branch --index-filter 'git rm --cached --ignore-unmatch <filename>' HEAD
правообладатель
– eleijonmarck
5 April 2018 в 06:00
Почему бы не использовать эту простую, но мощную команду?
git filter-branch --tree-filter 'rm -f DVD-rip' HEAD
Параметр --tree-filter
запускает указанную команду после каждой проверки проекта и затем подтверждает результаты. В этом случае вы удаляете файл с именем DVD-rip из каждого моментального снимка, независимо от того, существует он или нет.
См. эту ссылку .
fatal: bad revision 'rm'
, который я исправил с помощью "
вместо '
. Общая команда: git filter-branch --force --index-filter "git rm --cached -r --ignore-unmatch oops.iso" --prune-empty --tag-name-filter cat -- --all
– marcotama
4 October 2016 в 06:02
\
в качестве разделителя путей - даже в Windows. Мне пришлось использовать /
.
– marcotama
4 October 2016 в 06:17
git push --force
, иначе удаленное репо все еще не изменилось. – li2 22 July 2015 в 16:16git push --force
. Также стоит отметить: принудительные нажатия не могут быть разрешены пультом дистанционного управления (по умолчанию gitlab.com этого не делает. Пришлось «отменить защиту» от ветви). – MatrixManAtYrService 10 September 2015 в 15:51