Импортировать изменения в репозиторий git из универсального diff

Question

Я пытаюсь импортировать изменения из одной системы контроля версий (проприетарной и сложной) в git-репозиторий.В настоящее время я делаю это, выполняя скрипт, который просто синхронизируется с каждой ревизией по порядку и фиксирует это в репозитории git, но по разным причинам это стало неработоспособным.

Для каждой ревизии я могу получить универсальныйразличие, описывающее изменение.Мне кажется, что этого должно быть достаточно, чтобы импортировать историю в git, но я не могу понять, как заставить git сделать это.Похоже, мне нужно что-то среднее между git-apply и git-fast-import.Возможно, мне следует создать содержимое файла из предыдущей версии и diff, а затем использовать git-fast-import?Или, может быть, я должен отформатировать diff как git patch, сохранить его как файл и использовать git-apply?

У кого-нибудь есть для меня хорошие идеи?

РЕДАКТИРОВАТЬ: Причина синхронизации ификсация стала неработоспособной в два раза:

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

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

Answer 1

• Команда apply, которая принимает унифицированный diff и применяет его (т. Е. Не существует «формата git patch», она просто унифицирует diff; также git apply - будет с радостью читать стандартный ввод, поэтому не нужно ничего сохранять).

• Команда am берет файл в формате mbox с исправлениями, применяет и фиксирует каждое из них. Вы могли бы быть в состоянии легко сгенерировать это; это просто:

  From au@th.or Mon, 23 May 2011 14:49:12 +0200
  From: au@th.or
  Date: Mon, 23 May 2011 14:49:12 +0200
  Subject: First line of commit message
  Content-length: <bytes-until-next From>
  
  Other lines of commit message
  ---
  unified diff
  

  объединено для всех ревизий.

• Действительно, кажется, fast-import не принимает различия, но разве вы не можете просто попросить исходную систему вместо этого предоставить вам содержимое ревизии (которое будет обрабатывать двоичные файлы, для которых не может быть создан унифицированный diff)? Если нет, вы можете попросить fast-import предоставить вам предыдущее содержимое (с помощью команды cat-blob), исправить его и ввести снова.

Answer 2

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

1. мастер проверки git
2. синхронизация с централизованным VCS
3. git add -A
4. git commit -m "Synced from upstream"
5. функция git merge
6. регистрация в централизованном VCS
7. git checkout -b nextfeature

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