Перебазирование Git в ветку, которая будет создана позже

Question

Я работаю над проектом веб-сайта, который в настоящее время отслеживается в svn, но собирается перейти на git, как только у кого-то еще будет время настроить новый сервер и прочее.Это долгая история, но тем временем я создал свой собственный репозиторий git из некоторого имеющегося у меня кода и довольно много над ним поработал.Я не использовал git svn clone, потому что я за границей, и мое интернет-соединение странное и требует прокси для HTTP, и, похоже, оно не пропускает git svn.В любом случае, я разрабатывал в своем собственном репозитории git, но в конечном итоге, как только проект действительно будет импортирован должным образом, мне нужно будет перенести свою работу на клонированный материал git-svn.Будет git rebase работать должным образом для этого?

Одно из осложнений заключается в том, что на самом деле я работал на виртуальной машине, и для многих коммитов я не осознавал, что не установил user.name и записи конфигурации user.email, так что коммиты исходят от локального пользователя виртуальной машины, что немного странно.Было бы лучше просто собрать все мои изменения в файлы diff, а затем применить их поверх новой ветки, как только она будет создана?

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

Один из последних вопросов заключается в том, что если я импортирую репозиторий SVN через git svn (Я только что проверил, и, похоже, сейчас это работает) но я не добавляю файл authors, смогу ли я позже перенести свои изменения в правильно импортированную ветку с файлом authors?

О, новое осложнение.Я сам импортировал репозиторий SVN, используя git svn, изнурительный процесс, который занял большую часть двух дней при таком медленном соединении.Однако, окончательно завершив клонирование, я понял, что в репозитории SVN весь код находился в подкаталоге, но в моем репозитории git корень репозитория также был корнем каталога.Если это немного сбивает с толку, то в основном это выглядит так

SVN:

\dir\codez

мерзавец:

\codez

Как я могу объединить два репозитория?Я надеюсь, что я все еще смогу использовать rebase, но это кажется действительно странной ситуацией.Это звучит похоже на подмодули, но я не думаю, что это совсем то, что мне нужно.

Answer 1

Я не использовал git svn clone, потому что я за границей, и мое интернет-соединение странное и требует прокси для HTTP

Это должно сработать, если вы установите

http_proxy=http://username:passwword@pprroxyHost:proxyPort

или вы можете попробовать

http_proxyUser=username
http_proxyPassword=password
http_proxyHost=aProxyHost
http_proxyPort=aProxyPort

Будет ли git rebase работать должным образом для этого?

Общий ответ:да, потому что вы еще не опубликовали свою ветку Git.
Подробный ответ:сначала вам нужно будет выполнить перебазирование в вашу ветку, прежде чем объединять результат на master.Видишь этот ответ.
Это предпочтительный рабочий процесс, поскольку он позволяет вам разрешить любой конфликт в ваш ветвь перед объединением (или перебазированием, если вы хотите сохранить свою историю) вашей ветки с master.
На самом деле, ниже вы увидите, что создание специальной ветви "слияние" на самом деле является лучшей идеей.

не понял, что я не установил записи конфигурации user.name и user.email

Поскольку вы еще не опубликовали, вы можете использовать filter-branch чтобы изменить свои коммиты и изменить имя пользователя и адрес электронной почты

Небольшой sh-скрипт может помочь

#!/bin/sh

git filter-branch --env-filter '

n=$GIT_AUTHOR_NAME
m=$GIT_AUTHOR_EMAIL

case ${GIT_AUTHOR_NAME} in
        aSystemUserName) n="TheActual Name" ; m="TheActual@mailAddress" ;;
esac

export GIT_AUTHOR_NAME="$n"
export GIT_AUTHOR_EMAIL="$m"
export GIT_COMMITTER_NAME="$n"
export GIT_COMMITTER_EMAIL="$m"
'

вызовите этот скрипт из вашего репозитория, и все готово.

Во-первых, у меня была более старая редакция кода, в которой даже не было заголовка SVN, так что мне не хватало кое-чего сверх этого.Каков наилучший способ продолжить?

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

• код из SVN
• код, который вы не получили непосредственно из репозитория SVN.

смогу ли я позже перенести свои изменения в правильно импортированную ветку с файлом authors?

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

Answer 2

git-rebase зависит от наличия общего коммита где-то в истории.Это также происходит в пределах одного репозитория.Похоже, вы окажетесь в ситуации, в которой (а) новое импортированное репозиторий git-svn отделено от вашего, и (б) между ними не будет общих коммитов.Вероятно, в конечном итоге вам придется делать это с помощью исправлений, но git может помочь вам в этом.Ознакомьтесь со справочными страницами для git-format-patch и git-am.Первый может сгенерировать серию исправлений из ряда коммитов, а второй может взять эту серию исправлений и применить их - и все сообщения о фиксации и тому подобное будут сохранены.

Это даст вам возможность исправить вашу проблему user.name/email вы можете просто изменить их в заголовках исправлений и убедиться, что они правильно установлены в новом импортированном репозитории, прежде чем применять свои исправления!

Лучший способ справиться с вашим устаревшим исходным местом ("более старая редакция...это даже не было заголовком SVN"), вероятно, будет:

• приведите репозиторий SVN в исправное состояние со всеми внесенными изменениями
• импортируйте его с помощью git-svn
• создайте и проверьте ветку в старом коммите, с которого вы начали работать
• примените свою серию исправлений
• объедините эту ветвь в master, соответствующую текущему заголовку SVN

К счастью для меня, но в меньшей степени для вас, мне никогда не приходилось использовать git-svn, поэтому я не могу однозначно ответить на ваш вопрос об авторах файла.Однако, если я правильно понимаю, authors-file переводит SVN authors в git authors.Если автор изменится при коммите git, хэш изменится.Поэтому было бы важно не путаться с этой таблицей перевода и сделать все правильно с первого раза.

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

Answer 3

Вы можете создать новую нерожденную ветвь с помощью низкоуровневых инструментов:

$ git symbolic-ref HEAD refs/heads/new_branch

С помощью современного git вы можете перебазировать всю ветку, используя --root опция "git rebase".

Это может помочь, а может и не помочь в вашей ситуации.ИММВ.