В начальных шагах, которым вы следовали, я думаю, вы только что наткнулись на один из случаев, когда интеграция git / git-lfs не всегда идеально безупречна.
Команда reset
переместила бы вашу ветку ref обратно. На самом деле это не удалило бы нежелательную фиксацию (или связанные объекты); но обычно это не имеет значения, потому что эти объекты недоступны, поэтому они не будут отправлены с push
. Пока все хорошо... с ванильным мерзавцем.
НО: объекты LFS (реальное содержимое больших файлов) также не были удалены до вашего нажатия. Насколько я знаю (и ваш опыт, похоже, подтверждает это), LFS не пытается определить, доступны ли объекты LFS при отправке на удаленное устройство, что, в конце концов, кажется дорогостоящей проверкой. Учитывая, что ваше хранилище LFS предназначено для хранения множества больших двоичных файлов, и что LFS предназначено для снижения затрат, связанных с наличием большого объема ненужных данных в хранилище LFS, рентабельность обычно будет заключаться в том, чтобы просто отправлять все, что не нужно. на сервере - что, по-видимому, и произошло здесь.
И если вы не сталкиваетесь с ограничением физического хранилища на сервере, это может быть действительно нормально. Никакая выборка или получение — за исключением явного указания LFS отправлять вам все, что не предназначено для обычного использования — в любом случае приведет к загрузке этих файлов.
Но, возможно, у вашего хоста репо не хватает места для хранения. Или, может быть, вы просто хотите, чтобы они исчезли; Я не могу сказать, что буду винить тебя. То, что удаление файлов локально и принудительная отправка не приводит к удалению файлов с сервера, опять же, предусмотрено дизайном. (То же самое относится и к основным объектам git; вы можете принудительно отправить ссылку, чтобы сделать удаленный объект недоступным, но физически «очистка» удаленного объекта не зависит от какой-либо локальной очистки.)
Информацию об удалении файлов LFS из репозитория, размещенного на Bitbucket, можно найти здесь: https://www.atlassian.com/git/tutorials/git-lfs#deleting-remote-files
person
Mark Adelsberger
schedule
28.08.2017