git checkout - как мне поддерживать временные метки при переключении веток? - PullRequest
Новая
       1

git checkout - как мне поддерживать временные метки при переключении веток?

10 голосов
/ 20 марта 2012

Я часто переключаюсь назад и вперед между ветвями. У меня есть скрипт, который отправляет содержимое кассы в «работающую» среду, где я вижу, как выполняется код и его тестирование (это веб-приложение). Этот push-скрипт использует rsync в своей основе и использует временные метки, чтобы определить, какие файлы действительно должны быть переданы. Поскольку git-checkout, похоже, устанавливает временные метки для файлов на текущее время, rsync сообщает, что все файлы перемещаются вверх, только потому, что временные метки будут обновлены.

Как сделать так, чтобы git-checkout сохранял временные метки при переключении между ветками, чтобы rsync сообщал только об изменениях содержимого?

Я не хочу использовать аргумент контрольной суммы rsync, так как он очень медленный.

Ответы [ 3 ]

8 голосов
/ 31 января 2015

С Git 2.2.2+ (январь 2015 г.) ситуация должна быть лучше (касательно git checkout и отметок времени).

Отметка времени больше не должна перемещаться для файлов, которые уже обновлены при выполненииgit checkout.

См. коммит c5326bd от Джефф Кинг (peff) :

checkout $ tree: не выбрасывать неизменные записи индекса

Когда мы "git checkout $tree", мы:

  • извлекаем пути из $tree в индекс, а затем
  • проверить полученные записи на рабочем дереве.

Наш метод для первого шага довольно сложный;он забивает всю существующую запись индекса, даже если его содержимое одинаковое.
Это означает, что мы теряем нашу статистическую информацию, что приводит к checkout_entry, чтобы позже переписать весь файл с идентичным содержимым.

Вместо этого давайтепосмотрим, есть ли у нас идентичная запись уже в индексе, и в этом случае мы оставляем ее на месте.Это позволяет checkout_entry делать правильные вещи.
Наши тесты охватывают два интересных случая:

  1. Мы удостоверяемся, что файл без изменений не перезаписывается.
  2. Мы уверены, чточто мы обновляем файл, который в индексе неизменен (по сравнению с $tree), но имеет изменения рабочего дерева.
    Мы сохраняем старую запись в индексе, и checkout_entry может понять, что наша статистика не устарела.
5 голосов
/ 20 марта 2012

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

rsync должен эффективно обновлять метки времени и не передавать никаких данных, если изменились только метаданные. Вы можете проверить это с помощью «ускорения». Вы также можете попросить последние версии rsync детализировать изменения с флагом -i. Вы можете указать rsync не использовать временные метки (и использовать только контрольные суммы), пропустив -a или -t, но это не рекомендуется на справочной странице rsync(1).

1 голос
/ 24 мая 2013

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

  1. Я думаю, что это можно сделать разумным способом: когда файл обновленияA с файлом B,

    file_timestamp = (отметка времени (B)> отметка времени (A))?отметка времени (B): отметка времени (CURRENT);

  2. или она может быть настроена как настраиваемая опция.

...