Вообще любой вариант сведется к инициализации нового .git + cherry-pick последних коммитов из старого.

Насколько я понимаю, все эти манипуляции с git влияют на рабочее дерево. Мне же требуется упрощать именно служебное содержимое .git никак не затрагивая текущее рабочее дерево.

Проще говоря удалять из репа неактуальные уже старые коммиты.

Да не может такого быть. У ветки своя история. И если там 100 коммитов, то ребаз будет долгим только если автор этих коммитов делал что-то не то. Например, решил, что закинуть свою видео коллекцию в гит - неплохая идея.

У ветки своя история.

Ты представляешь, как ребейз работает? Сто коммитов заново по одному накладываются, и для каждого пересчитывается хэш

да неважно сколько гигов в репозитории, если ребейзятся последние 100 коммитов и каждый из них не мегабайтные изменения содержит

Что с поддержкой хешей отличных от SHA-1? Когда будет?

А нахрена?

Ты просто не умеешь его готовить, используй git-annex.

https://github.com/git-for-windows/git/releases

Changes since Git for Windows v2.19.2 (November 21st 2018)

Please note that Git for Windows v2.19.2 was offered as a full release only for about a week, and then demoted to «pre-release» status, as it had two rather big regressions: 32-bit Git Bash crashed, and git:// was broken.

Лучше дай ссылку сюда ;-)

А когда в гите можно будет, наконец-то, как в ртути писать: git co, git st, git bra?..

на PHP был

Насколько я понимаю, все эти манипуляции с git влияют на рабочее дерево.

Строго говоря, git использует working tree для, ВНЕЗАПНО, своей работы.

Если тебе надо не трогать файлы в этом месте, тебе нельзя использовать репозиторий с working tree по этому пути.

Для тебя только один вариант - rsync'ать файлы в working tree, которое потом можно почистить, переключив репу на bare-режим.

пока можно так (если настроено атводополнение): git com<tab><tab>, git st<tab><tab>, git bra<tab><tab>

А если не лень дописать, то поддерживаются алиасы, называй как хочешь.

да неважно сколько гигов в репозитории

Может и не важно, но от этого быстрее оно не шевелится

https://github.com/git/git/blob/master/Documentation/technical/hash-function-...

https://stackoverflow.com/a/47838703

раст не нужен, пускай на нём мозиллу пишут :)

Внезапно. Вы использовали его на практике? Плюсы, минусы, подводные баги?

А когда в гите можно будет, наконец-то, как в ртути писать: git co, git st, git bra?..

Пишу так с 2010 года:

[alias]
    cl = clone
    cm = commit
    cs = commit -S
    ca = commit -a
    co = checkout
    st = status
    lt = log -1 HEAD
    lg = log --decorate --graph --format=fuller
    ll = log --pretty=oneline --abbrev-commit
    unchange = checkout --
    unstage = reset HEAD --
    br = branch
    lb = branch -v -a
    distclean = !git clean -fdx && git checkout -- .
    info = count-objects -vH
    zip = !git archive `git rev-parse --abbrev-ref HEAD` --prefix="`pwd | xargs basename`/" --format=zip > `pwd | xargs basename`.zip

Невпихулемо

Вы использовали его на практике? Плюсы, минусы, подводные баги?

Пока нет. Основной минус пихуля в том что он не git => не работает magit, github/gitlab и прочее. Если бы сделали работу pijul'я с git'овыми репами, как git-svn работает с Subversion'овскими, то можно я значительно усилил бы стремление к увеличению намерения его попробовать.

Пока обещают только что pijul будет быстрее работать на некоторых операциях, особенно с большими репами и длинными историями, но мне это не актуально.

За `zip` гранд мерси =)

Да нет, рабочее дерево в норме должно меняться только тогда, когда об этом попросил пользователь путем непосредственного редактирования файлов или чекаутов файлов из репа.

В данном случае речь идет о редактировании истории (лога) репа, а именно удалении или объединении отдельных коммитов из истории и переупаковки с целью оптимизации оного. Рабочее дерево при этом как отражало, так и отражает текущее состояние и меняться не должно.

При помощи `git-filter-branch`. Вот рецепты со Stack Overflow

Да git-annex то каким образом?

мне он нужен как раз чтобы файлы были в репе и я всегда мог вернуть их на тот или иной коммит. Собственно, все работает. Просто со временем история переполняется и мне хотелось бы иметь возможность удалять все ненужные состояния файлов, в идеале, например, можно было бы удалять все коммиты старше чем год назад при условии что есть хоть один коммит, все коммиты старше одного месяца при условии что за этот месяц есть хоть один коммит, все коммиты за текущий месяц старше недели, при условии что есть хоть один коммит за эту неделю ну и все.

Таким образом, если делать коммиты каждый день, то за последнюю неделю имеем коммиты на каждый день, каждую неделю за месяц и каждый месяц за год.

Так, в этом случае, вероятно, нужно не отрубать хвост совсем, а прореживать историю коммитов, выкидывая какие-то промежуточные состояния. Вообще, если определить политику прореживания/отрубания почетче, то можно было бы написать готовый рецепт (скрипт для `filter-branch`)

Чего-нибудь автоматизировать на базе `rebase --interactive`, делая squash.

Естественно, самое важное, это отрубать хвост совсем. И без этого никак, иначе реп будет бесконтрольно расти до тех пор, пока не переполнит все пространство. Все остальное это уже хотелки.

Для архивации есть zbackup.

duplicity ?

AFAIK zbackup гораздо ближе к git по внутреннему устройству А duplicity... по-моему, если не надо бэкапить на Amazon, смысла в ней нет никакого.

Да нет, рабочее дерево в норме должно меняться только тогда, когда об этом попросил пользователь

Оно и меняется тогда, когда ты попросил - запустив git с командой, требующей работы с файлами.

Рабочее дерево при этом как отражало, так и отражает текущее состояние и меняться не должно.

Не надо свои фантазии приплетать к реальному устройству мира. В working tree содержится то, на что указывает HEAD, а не то, что ты там себе фантазируешь.

И это правильно, потому что когда в ходе изменения истории тебе потребуется разрулить руками конфликт, куда ты пойдешь? Именно. Благодрая git'у ты пойдёшь редактировать файлы в working tree, а не туда, куда следовало бы идти любителям рассказывать, как должен быть устроен для них весь остальной мир, без единой долговой расписки на руках.

Для не Ъ отвечу: https://plus.google.com/ LinusTorvalds/posts/7tp2gYWQugL

Вопрос так и не снят: нахрена стойкий криптографический хеш в гите?

Если бы сделали работу pijul'я с git'овыми репами

Казалось бы это невозможно, учитывая что pijul на патчах, а git на снапшотах.

Вот вопрос, кстати, про zbackup. Я его рассматривал, как возможный инструмент для бекапа, но забраковал по следующей причине.

В описании сказано, что метод использования — это подать на вход ему tar-архив, который он сам на куски порежет, пожмёт и дедуплицирующе сохранит. Вопрос: вот я отдаю ему какой-то один жирный затаренный каталог всё время, а потом в один день внутри этого каталога перемещаю файлы из одного места в другое и снова отдаю zbackup.

Судя по описанию zbackup, он не отловит факт того, что это те же файлы, но в другом порядке. И наскладирует куски этих файлов заново. То есть дедупликация хреновая получается.

Я неправильно понимаю алгоритм работы?

Судя по описанию zbackup, он не отловит факт того, что это те же файлы, но в другом порядке.

По описаню. zbackup я сужу, что он всё отловит, но специально не проверял. Можешь процитировать место из документации, по которому сделал вывод?

Да, отловит, это я недочитал второй абзац текста на сайте.

This is achieved by sliding a window with a rolling hash over the input at a byte granularity and checking whether the block in focus was ever met already. If a rolling hash matches, an additional full cryptographic hash is calculated to ensure the block is indeed the same. The deduplication happens then.

Попробовал поперемещать файлы в разные каталоги и побекапить — все перемещения отлавливает. Прикольна.

Я думаю, о каталогах он тупо ничего не знает - на входе тарбол, но может быть вообще любой файл.

Да-да, он побайтово отлавливает совпадения. Это очень круто, на самом деле, я как-то пропустил этот факт при беглом знакомстве.