rebasing git para um ramo que será criado depois

Question

Eu estou trabalhando em um projeto de web site que está rastreado no SVN, mas vai se mover para o git uma vez alguém tem tempo para configurar um novo servidor e outras coisas. É uma longa história, mas, entretanto, eu fiz o meu próprio repositório git de algum código que eu tinha, e trabalhou com ele um pouco. Eu não usar git svn clone porque eu estou no exterior e minha conexão com a internet é estranho e requer um proxy para HTTP, e não parece deixar svn git completamente. Em qualquer caso, eu tenho vindo a desenvolver no meu próprio repositório git, mas, eventualmente, uma vez que o projeto realmente é importado corretamente eu vou necessidade de rebase meu trabalho para o material clonado git-svn. Vai git rebase trabalho adequadamente para isso?

Uma complicação é que eu estava realmente trabalhando em uma máquina virtual e para muitos commits Eu não tinha percebido que eu não tinha definido o user.name e entradas de configuração user.email assim os commits são de usuário local do vm, que é meio estranho. Seria melhor apenas para reunir todas as minhas alterações em diff arquivos e, em seguida, aplicá-las em cima da nova filial uma vez que é criado?

Outra complicação é que o uso SVN antes era uma espécie de tímida, então não eram realmente alterações não confirmadas no servidor de produção que eu não tinha. Na verdade, eu tinha uma revisão mais antiga do código em primeiro lugar que não era mesmo o chefe SVN, então eu estava faltando alguma coisa em cima disso. Qual é a melhor maneira de proceder?

Uma questão final é que se eu fizer importar o repositório SVN via git svn (Acabei de verificar e parece estar trabalhando agora), mas eu não adicionar um arquivo autores, vai mais tarde ser capaz de rebase minhas alterações na um ramo correctamente importadas com um arquivo autores?

Oh, uma nova complicação. Eu importado o SVN repositório me usando git svn, um processo cansativo que levou a melhor parte de dois dias nesta conexão lenta. No entanto, depois de finalmente terminar o clone, percebi que no SVN repositório do código era tudo em um subdiretório, mas no meu repositório git da raiz do repositório também foi a raiz do diretório. Se isso é um pouco confuso, é basicamente como este

SVN:

\dir\codez

git:

\codez

Como posso combinar os dois repositórios? Espero que eu ainda pode usar rebase, mas esta parece ser uma situação muito estranha. Parece semelhante ao submódulos, mas eu não acho que isso é exatamente o que eu preciso.

Answer 1

Eu não usar git svn clone porque eu estou no exterior e minha conexão com a internet é estranho e requer um proxy para HTTP

Ele deve funcionar se você definir

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

ou você pode tentar

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

Será git trabalho rebase corretamente para isso?

resposta

Geral:., sim, porque você não ter publicado o seu ramo Git ainda
resposta detalhada: terá de rebase em seu ramo em primeiro lugar, antes de fundir o resultado no mestre. Consulte esta resposta .
Este é o trabalho preferido, já que permite resolver qualquer conflito no o ramo antes de se fundir (ou rebasing se você quer manter sua história) o seu ramo para mestre.
Na verdade, você verá a seguir que a criação de um especial ramo "merge" é na verdade uma idéia melhor.

não tinha percebido que eu não tinha definido o user.name e user.email configuração entradas

Uma vez que você ainda não publicado, você pode usar um filter-branch para modificar seus commits e alterar o nome de usuário e e-mail

Um script sh pouco pode ajudar

#!/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"
'

chamar este script em sua repo e você está feito.

Eu tive uma revisão mais antiga do código em primeiro lugar que não era mesmo o chefe SVN, então eu estava faltando alguma coisa em cima disso. Qual é a melhor maneira de proceder?

O fluxo de trabalho básico neste caso é o de criar um novo ramo "merge" do seu atual ramo de trabalho, a fim de isolar o esforço rebase (e resolver todos os conflitos)
Neste tipo de merge onde o delta é importante, você deve manter seu ramo de trabalho limpo de todas as mudanças que você precisa fazer a fim de incluir:

• O código do SVN
• o código que você não obter diretamente do repositório SVN.

Eu vou mais tarde ser capaz de rebase minhas alterações em um galho correctamente importadas com um arquivo autores?

Eu não tenho certeza, mas eu acho que não. Se não, contanto que você não publicou nada ainda, você pode querer usar um script filter-branch renomeação de novo ...

Answer 2

git-rebase depende de ter um comum cometer algum lugar na história. Também ocorre dentro de um único repositório. Parece que você está indo para acabar em uma situação em que (a) o novo repositório git-svn importado é separado do seu, e (b) não haverá commits comuns entre os dois. Você provavelmente vai acabar precisando de fazer isso via manchas, mas git pode ajudá-lo com isso. Confira as manpages para git-format-patch e git-am. O primeiro pode gerar uma série de manchas de uma série de commits, eo segundo pode levar esta série de manchas e aplicá-los -. E todas as mensagens cometer e tais serão preservados

Isto irá fornecer-lhe uma oportunidade para corrigir o problema user.name/email - você pode simplesmente modificá-los nos cabeçalhos das manchas, e se certificar de que está pronto corretamente no novo repo importados antes de aplicar seus patches!

A melhor maneira de lidar com o seu fora de data de início lugar ( "revisão mais antiga ... que não era mesmo o chefe SVN") é provavelmente vai ser:

• obter o repo SVN em um estado bom, com todas as alterações comprometida
• importá-lo com git-svn
• criar e verificar uma filial em um velho cometer onde você começou a trabalhar a partir
• aplicar sua série de patch
• fundir este ramo em mestre, correspondente à cabeça SVN atual

Felizmente para mim, mas nem tanto para você, eu nunca precisei usar git-svn, então não posso responder à sua pergunta autores-file definitivamente. No entanto, se bem entendi, o autores-file traduz SVN autores em autores git. Se uma das mudanças autor sobre um git commit, o hash vai mudar. Por isso, seria importante não mexer com esta tabela de tradução, e obtê-lo logo na primeira vez.

Houve um monte de perguntas em um aqui, tão à vontade para comentar e pedir mais se eu perdi coisas.

Answer 3

Você pode criar novo ramo por nascer com ferramentas de baixo nível:

$ git symbolic-ref HEAD refs/heads/new_branch

Com git moderno você pode rebase ramo inteiro usando a opção --root de "rebase git".

Este poder, ou não, ajuda na sua situação. YMMV.