Git format-patch для совместимости с svn?

Ответ 1

Мне всегда нужно это делать Google, но так, как я нашел, что работает отлично (для меня):

• Создайте патч с помощью git diff --no-prefix master..branch > somefile.diff, основная часть и ветка являются необязательными, зависит от того, как вы хотите получить свои отличия.
• Отправить его везде и применить с помощью patch -p0 < somefile.diff.

Кажется, что все работает отлично для меня и, кажется, самый простой метод, с которым я столкнулся.

Ответ 2

Короткий ответ - patch -p1 -i {patch.file}.

Подробности см. В этом блоге: Создание патчей Subversion с git.

Ответ 3

Здесь помощник script для создания разницы с последним набором изменений svn и данным фиксацией: http://www.mail-archive.com/[email protected]/msg00864.html

#!/bin/sh
#
# git-svn-diff
# Generate an SVN-compatible diff against the tip of the tracking branch
TRACKING_BRANCH=`git config --get svn-remote.svn.fetch | sed -e 's/.*:refs\/remotes\///'`
REV=`git svn find-rev $(git rev-list --date-order --max-count=1 $TRACKING_BRANCH)`
git diff --no-prefix $(git rev-list --date-order --max-count=1 $TRACKING_BRANCH) $* |
sed -e "s/^+++ .*/&    (working copy)/" -e "s/^--- .*/&    (revision $REV)/" \
-e "s/^diff --git [^[:space:]]*/Index:/" \
-e "s/^index.*/===================================================================/"

Ответ 4

SVN, вероятно, не может понять вывод git diff -p, но вы можете прибегнуть к грубой силе:

• Сделайте два клона вашего репо
• В одном клоне проверьте свои последние материалы.
• В другой проверке клона, что эквивалентно svn upstream. Если вы планировали заранее, у вас есть копия svn вверх по течению в своей ветке, или вы отметили последнюю версию svn. Если вы еще не планировали, используйте дату или gitk, чтобы найти хэш git SHA1, который наиболее близко приближается к состоянию svn.
• Теперь вычислите реальный патч, выполнив diff -r над двумя клонами.

Ответ 5

Subversion < 1.6 не поддерживает исправления. Похоже, Subversion 1.7 позволит применять исправления, а расширения git/hg для унифицированного diff находятся в нашем списке TODO.

Ответ 6

Это действительно запрос функции в начале 2008 года

Линус Торвальдс сказал в то время:

Поэтому я бы сказал, что вам нужно что-то более сильное, чтобы сказать "не делайте git diff", и это должно также запретить обнаружение переименования как минимум.
Совершенно откровенно, любая программа, которая настолько глупа, чтобы не принимать текущие git-патчи (то есть TortoiseSVN), тогда мы чертовски хорошо не должны просто отключать самую тривиальную ее часть. Мы должны убедиться, что мы не включили ни одного из довольно важных расширений:
даже если ToirtoiseSVN проигнорирует их, если их игнорировать означает, что он неправильно понимает diff, его не следует допускать вообще.

Возможно, поэтому

 git-format-patch: add --no-binary to omit binary changes in the patch.

был введен в Git1.5.6 в мае/июле 2008 года (я его еще не тестировал)

Ответ 7

Убедитесь, что ваши изменения зафиксированы и переустановлены поверх локальной ветки git из git bash run:

git show --pretty → myChangesFile.patch

Ответ 8

Принятый ответ Николаса отлично работает, за исключением случаев, когда a) бинарные файлы существуют в diff или b) вы работаете в windows Git и имеете каталоги с пробелами. Чтобы получить это решение, мне пришлось добавить вложенную команду Git diff, чтобы игнорировать двоичные файлы и команду sed, чтобы избежать пробелов. Это немного громоздко писать, поэтому я создал псевдоним:

[alias]
svnpatch = "!f() { git diff --name-only --no-prefix master...$1 | grep -Ev \"\\.sdf|\\.Doc|\\.dll|\\.zip|\\.exe\" | sed 's_\\s_\\\\\\\\ _g'  | xargs git diff --no-prefix master...$1 > $1.patch; echo "Created $1.patch"; }; f"

Если вы затем наберете:

git svnpatch Feature123

... файл исправления Feature123.patch будет создан с различиями между базой слияния ведущего сервера и веткой Feature123.