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

Question

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

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

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

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

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

SVN:

\dir\codez

мерзавец:

\codez

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

Answer 1

Я не использовал Git SVN клон, потому что я за границей, и мое подключение к Интернету странно и требует прокси для HTTP

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

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

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

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

Будет ли git rebase работать правильно для этого?

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

не понял, что я не установил user.name и user.email CONFIG записей из

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

немного ш скрипт может помочь

#!/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.

буду позже я иметь возможность перебазировать свои изменения на правильно импортируемую отрасль с авторами-файлом?

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

Answer 2

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

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

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

• получить репозиторий SVN в хорошем состоянии, все изменения, совершенные
• импортировать его с GIT-SVN
• создания и проверки из филиала в старой фиксации, где вы начали работать с
• применять ваш патч серии
• объединить эту ветку в мастер, соответствующий текущей главы SVN

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

Здесь было много вопросов, поэтому не стесняйтесь комментировать и просить больше, если я пропущу вещи.

Answer 3

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

$ git symbolic-ref HEAD refs/heads/new_branch 

С современным мерзавцем вы можете перебазироваться целой отраслью, используя --root вариант «мерзавец перебазироваться».

Это может помочь или может не помочь в вашей ситуации. YMMV.