Esegui il rebasing su un ramo che verrà creato in seguito

Question

Sto lavorando a un progetto di un sito web che è attualmente tracciato in svn ma sta per passare a git quando qualcun altro ha il tempo di impostare un nuovo server e cose. È una lunga storia, ma nel frattempo ho creato il mio repository git da un po 'di codice che avevo e ci ho lavorato un po'. Non ho usato il clone di git svn perché sono all'estero e la mia connessione a Internet è strana e richiede un proxy per HTTP, e non sembra lasciar passare git svn. In ogni caso, sto sviluppando nel mio repository git, ma alla fine una volta che il progetto sarà effettivamente importato correttamente, dovrò rifare il mio lavoro sulla roba clonata git-svn. git rebase funzionerà correttamente per questo?

Una complicazione è che stavo effettivamente lavorando in una macchina virtuale e per molti commit non mi ero reso conto di non aver impostato le voci di configurazione user.name e user.email in modo che i commit provenissero dall'utente locale della VM, che è un po 'strano. Sarebbe meglio raccogliere tutte le mie modifiche in file diff e poi applicarle in cima al nuovo ramo una volta creato?

Un'altra complicazione è che l'uso di SVN prima era un po 'sconcertante, quindi c'erano effettivamente delle modifiche non confermate sul server di produzione che non avevo. In realtà, all'inizio avevo una revisione più vecchia del codice che non era nemmeno la testa SVN, quindi mi mancavano alcune cose. Qual è il modo migliore per procedere?

Un'ultima domanda è che se importare il repository SVN tramite git svn (ho appena controllato e sembra funzionare ora) ma non aggiungo un file dell'autore, dovrei in seguito potrai reimpostare le mie modifiche su un ramo importato correttamente con un file degli autori?

Oh, una nuova complicazione. Ho importato personalmente il repository SVN usando git svn , un processo estenuante che ha richiesto la parte migliore di due giorni su questa connessione lenta. Tuttavia, dopo aver finalmente finito il clone, mi sono reso conto che nel repository SVN il codice era tutto in una sottodirectory, ma nel mio repository git la radice del repository era anche la radice della directory. Se questo è un po 'confuso, è sostanzialmente così

SVN:

\ dir \ codez

git:

\ codez

Come posso combinare i due repository? Spero di poter ancora usare rebase, ma questa sembra una situazione davvero strana. Sembra simile ai sottomoduli, ma non credo sia proprio quello di cui ho bisogno.

Answer 1

  

Non ho usato git svn clone perché sono all'estero e la mia connessione Internet è strana e richiede un proxy per HTTP

Dovrebbe funzionare se imposti

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

oppure puoi provare

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

  

Git rebase funzionerà correttamente per questo?

Risposta generale: sì, perché non hai ancora pubblicato la tua filiale Git.
Risposta dettagliata: dovrai rifare prima il ramo, prima di unire il risultato sul master. Vedi questa risposta .
Questo è il flusso di lavoro preferito poiché ti consente di risolvere qualsiasi conflitto nel ramo del tuo prima di unire (o riformare se vuoi conservare la tua cronologia) il tuo ramo nel master.
In realtà, vedrai di seguito che la creazione di una speciale "quotazione" " branch è in realtà un'idea migliore.

  

non si era reso conto di non aver impostato le voci di configurazione user.name e user.email

Dato che non hai ancora pubblicato, puoi utilizzare un filtro-ramo per modificare i tuoi commit e cambiare il nome utente e l'e-mail

Un piccolo script sh può aiutare

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

chiama questo script dal tuo repository e il gioco è fatto.

  

In primo luogo ho avuto una versione precedente del codice che non era nemmeno la testa SVN, quindi mi mancavano alcune cose. Qual è il modo migliore per procedere?

Il flusso di lavoro di base in questa istanza è creare un nuovo " unisci " ramo dal tuo attuale ramo di lavoro al fine di isolare lo sforzo di rebase (e risolvere tutti i conflitti)
In questo tipo di unione in cui il delta è importante, è necessario mantenere pulito il proprio ramo di lavoro da tutte le modifiche che è necessario apportare per includere:

• il codice da SVN
• il codice che non hai ricevuto direttamente dal repository SVN.

  

potrò in seguito riordinare le mie modifiche su un ramo importato correttamente con un file dell'autore?

Non ne sono sicuro ma penso di sì. In caso contrario, finché non hai ancora pubblicato nulla, potresti voler utilizzare nuovamente uno script di rinomina filtro-ramo ...

Answer 2

git-rebase dipende dall'avere un commit comune da qualche parte nella storia. Si verifica anche all'interno di un singolo repository. Sembra che finirai in una situazione in cui (a) il nuovo repository importato git-svn è separato dal tuo e (b) non ci saranno commit comuni tra i due. Probabilmente finirai per doverlo fare tramite patch, ma git può aiutarti in questo. Dai un'occhiata alle manpage per git-format-patch e git-am . Il primo può generare una serie di patch da una serie di commit e il secondo può prendere questa serie di patch e applicarle - e tutti i messaggi di commit e simili verranno conservati.

Questo ti darà l'opportunità di risolvere il tuo problema user.name/email: puoi semplicemente modificarli nelle intestazioni delle patch e assicurarti che siano impostati correttamente nel nuovo repository importato prima di applicare le patch!

Il modo migliore per gestire il tuo posto di partenza obsoleto ("revisione precedente ... che non era nemmeno il capo SVN") sarà probabilmente:

• riporta in buono stato il repository SVN, con tutte le modifiche apportate
• importalo con git-svn
• crea e controlla una filiale in un vecchio commit da cui hai iniziato a lavorare
• applica le tue serie di patch
• unisce questo ramo in master, corrispondente all'attuale testina SVN

Fortunatamente per me, ma meno per te, non ho mai avuto bisogno di usare git-svn, quindi non posso rispondere in modo definitivo alla tua domanda sul file degli autori. Tuttavia, se ho capito bene, il file degli autori traduce gli autori SVN in autori git. Se un autore cambia su un commit git, l'hash cambierà. Sarebbe quindi importante non scherzare con questa tabella di traduzione e farlo bene la prima volta.

Ci sono state molte domande in una qui, quindi sentiti libero di commentare e chiedere di più se ho perso delle cose.

Answer 3

Puoi creare un nuovo ramo non nato con strumenti di basso livello:

$ git symbolic-ref HEAD refs/heads/new_branch

Con git moderno puoi rifare l'intero ramo usando l'opzione --root di " git rebase " ;.

Questo potrebbe o meno aiutare nella tua situazione. YMMV.