Слияние изменений извне git-репозитория

Question

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

Когда я получаю его обновленный код, он обычно имеет форму zip-файла. Если я просто разархивирую файл в свою рабочую папку git, git считает, что каждый файл изменился, предположительно, из-за изменения статистики.

То, что я хотел бы увидеть, - это способ распаковать новый код вместе с моей рабочей копией и объединить только изменения. Какой лучший способ сделать это? Поскольку это проект Powerbuilder, большинство файлов являются двоичными файлами.

Спасибо!

Answer 1

Двоичные файлы, если они хранятся в Git, должны создавать новую версию (т.е. учитываться при следующем коммите).
Итак: вам нужны эти двоичные файлы, или вы можете восстановить их?

Что касается источников, в Git SHA1 является королем , а , поскольку дата файла (временные метки) участвует в его вычислении , поскольку внешний набор файлов может быть довольно разным по своему содержанию (больше файлов, временных файлов, файлов, которые следует игнорировать, ...), было бы лучше:

• распаковать в отдельную директорию
• используйте инструмент, подобный WinMerge , чтобы обнаружить изменения, основанные на содержимом, объединить их, а затем зафиксировать только те файлы, которые фактически развились.
  Вы просто сравниваете два набора каталогов и файлов: тот, в котором вы разархивировали разработку своего далекого коллеги, и тот, в котором вы сейчас работаете.

---

Спасибо rq за указание на то, что временные метки не являются частью вычисления SHA1. Только:

• тип
• размер
• содержимое блоба

являются частью вычисления SHA1 :
_{(источник: alexgirard.com )}

Однако при импорте большого набора файлов, управляемых извне, в репозиторий git, вы рискуете добавить новые файлы в каталоги, управляемые git, изменить их содержимое, следовательно, их ключ SHA1, даже если старые файлы, управляемые git, не изменились. 1044 * Это означает, что многие изменения в дереве являются искусственными, если эти новые файлы являются просто временными файлами или файлами, которые в любом случае следует игнорировать / создавать заново / восстанавливать.

_{(источник: alexgirard.com )}

Вышеописанный процесс просто обеспечивает внешний способ определения того, что изменилось между набором файлов external и набором файлов, управляемым git, и определяет, должен ли он быть частью рабочего каталога git или нет.

Answer 2

это, хотя и не совсем уверенная хорошая идея, это то, что я думаю сделать в почти такой же ситуации:

как насчет поддержания репо для них?

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

Answer 3

Проверьте, будет ли contrib/fast-import/import-zips.py делать то, что вы хотите.