Обновить
87
zerkms@zerkms

Пользователь

50
Подписчики
Отправить сообщение
PPS:

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

ps: я бы даже сказал, что будут почищены недоступные объекты, которые могут возникнуть в случае git reset, удаления несмердженного бренча, итд

Поясните, что именно вы хотели сказать, потому как на данном этапе это не совсем ясно.
Эм, куда ему ещё уменьшаться? Я же показал своим примером, что содержимое файла дважды не пишется. М?
Я с этим и не спорю :-)

Изначальная фраза, которую я комментировал:

> Git при переименовании файлов реально удаляет файл, а затем создает файл с таким же содержимым и новым именем.

Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.

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

Но, если вспомнить проблему со взломом серверов kernel.org — команда разработчиков проверяла достоверность по каким-то своим цифровым подписям, не доверяя хэшу.

(хотя я не совсем детально в это всё вникал, возможно я и наговорил какую-то фигню :-)
Он поддерживает переименование и автообнаружение, но само хранилище НЕ УМЕЕТ до сих пор (хотя в трекере периодически создаются соответствующие баги) в самом индексе переименовывать файл. Как результат получаем удвоение размера.

Вот вам пример:

$ du -sh .hg
2.6M .hg

$ hg mv binary binary2

$ hg st
A binary2
R binary

$ hg commit -m «rename»

$ du -sh .hg
5.0M .hg
Провёл эксперимент
$ du -sh .git/
484K .git/

$ git mv binary binary2

$ git status
# On branch master
# Changes to be committed:
# (use «git reset HEAD ...» to unstage)
#
# renamed: binary -> binary2
#

$ git commit -am «rename»
[master 1b8d156] rename
1 file changed, 0 insertions(+), 0 deletions(-)
rename binary => binary2 (100%)

$ du -sh .git
500K .git

ps: отдельное спасибо минусовавшим, которые не разобравшись жмут на кнопку. Удачного вам дня.
Из того, что в команде diff есть такие ключи, не значит, что git не умеет нормально переименовывать файлы. Верно?
> Git при переименовании файлов реально удаляет файл, а затем создает файл с таким же содержимым и новым именем.

Точно? Насколько помнится, такая проблема существовала в меркуриале, но не в гите.
Вы уже запостили баг в их трекер?
Нашёл: Кент Бек, книга о TDD
Не могу вспомнить и нагуглить автора:

«Поставьте на рабочий стол бутылку с водой и периодически отпивайте из неё: организм сам подскажет, когда сделать перерыв»

ps: подскажите автора, не успокоюсь, пока не узнаю :-)
То же самое говорили и твиттеру.
Может быть там только реплики? Я в их выступлениях видел (как минимум в том, где они расказывали об инвалидации кэша), что они говорили про то, что вся запись уходит всегда в один ДЦ, а остальные выбираются географически и фактически работают быстрым и близким к юзеру кэшем.
> Известны случаи, когда после увольнения, пропадали исходники работы и приходится все переписывать заново.

А как же центральный репозиторий компании? Или сотрудник работал несколько месяцев, ничего не комитил и ни у кого это вопросов не вызвало? :-)
Занимательно, что ещё никто не предложил залить на гитхаб (ну или на битбакет). Предлагаю :-)
Я могу повторить: это публичное место. Если вы не можете сдержанно реагировать на комментарии других людей — тогда вам, вероятно, более подошёл бы другой способ общения.
В вашем комментарии был единственный вопрос. Я и не мог предположить, что даже при ответе на единственный вопрос нужно в явном виде его ещё раз процитировать.
> Но спрашивали не вас. Высказать точку зрения — всегда пожалуйста, но встревать между диалога — не красиво как минимум.

Хабр — публичный блог. Если вы не хотите, чтобы на ваши комментарии отвечали другие люди или если вы не можете относиться к комментаторам толерантно — вы могли бы выбрать другие способы общения с тем человеком. Такие, чтобы другие люди не смогли чисто технически «встрять» в вашу беседу.

Спасибо пожалуйста.
Ничего не так, я лишь ответил на чужой вопрос «Сами придумали?». Нет, никто не придумывал.

Я и не пытался даже убедить кого-то, что один термин правильнее другого, я лишь указал на то, что оба имеют место быть.

Информация

В рейтинге
Не участвует
Откуда
Веллингтон, Wellington, Новая Зеландия
Зарегистрирован
Активность