Git rebasant sur une branche qui sera créée plus tard

Question

Je travaille sur un projet de site Web qui est actuellement suivi dans svn mais qui va passer à git une fois que quelqu'un d'autre aura le temps de configurer un nouveau serveur et d'autres éléments. C'est une longue histoire, mais dans l'intervalle, j'ai créé mon propre référentiel git à partir d'un code que j'avais, et j'ai beaucoup travaillé dessus. Je n'ai pas utilisé git svn clone parce que je suis à l'étranger et que ma connexion Internet est étrange et nécessite un proxy pour HTTP, et cela ne semble pas laisser passer git svn. Dans tous les cas, je développe dans mon propre référentiel git, mais une fois le projet correctement importé, je vais devoir reformer mon travail sur le matériel cloné git-svn. git Rebas fonctionnera-t-il correctement pour cela?

Une des complications est que je travaillais réellement sur une machine virtuelle et que, pour de nombreux commits, je n'avais pas réalisé que je n'avais pas défini les entrées user.name et user.email config. Les commits proviennent donc de l'utilisateur local de la machine virtuelle, ce qui est un peu bizarre. Serait-il préférable de rassembler toutes mes modifications dans des fichiers diff, puis de les appliquer au-dessus de la nouvelle branche une fois celle-ci créée?

Une autre complication est que l’utilisation du SVN auparavant était plutôt timide, il y avait donc des modifications non validées sur le serveur de production que je n’avais pas. En fait, j'avais une version plus ancienne du code qui n'était même pas la tête de SVN, donc il me manquait des trucs en plus. Quelle est la meilleure façon de procéder?

Une dernière question est que si j'importe le référentiel SVN via git svn (je viens de vérifier et cela semble fonctionner maintenant), mais je n'ajoute pas de fichier-auteurs, puis-je Plus tard, je pourrai reformer mes modifications sur une branche correctement importée avec un fichier authors?

Oh, une nouvelle complication. J'ai moi-même importé le référentiel SVN en utilisant git svn , un processus éprouvant qui a pris environ deux jours sur cette connexion lente. Cependant, après avoir finalement terminé le clone, je me suis rendu compte que dans le référentiel SVN, le code était tout dans un sous-répertoire, mais que dans mon référentiel git, la racine du référentiel était également la racine du répertoire. Si c'est un peu déroutant, c'est fondamentalement comme ça

SVN:

\ dir \ codez

git:

\ codez

Comment puis-je combiner les deux référentiels? J'espère que je peux toujours utiliser rebase, mais cela semble être une situation vraiment étrange. Cela ressemble aux sous-modules, mais je ne pense pas que ce soit ce dont j'ai besoin.

Answer 1

  

Je n'ai pas utilisé git svn clone parce que je suis à l'étranger et que ma connexion Internet est étrange et nécessite un proxy pour HTTP

Cela devrait fonctionner si vous définissez

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

ou vous pouvez essayer

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

  

Git Rebase fonctionnera-t-il correctement pour cela?

Réponse générale: oui, car vous n'avez pas encore publié votre branche Git.
Réponse détaillée: vous devrez d'abord vous baser sur votre branche avant de fusionner le résultat sur le maître. Voir cette réponse .
Il s'agit du flux de travaux préféré car il vous permet de résoudre tout conflit dans votre branche avant de fusionner (ou de rebasonner si vous souhaitez conserver votre historique) de votre branche sur le maître.
En fait, vous verrez ci-dessous que la création d'un fichier spécial "fusion". branche est en fait une meilleure idée.

  

n'avait pas réalisé que je n'avais pas défini les entrées user.name et user.email config

Comme vous n'êtes pas encore publié, vous pouvez utiliser une branche de filtre pour modifier vos validations et modifier le nom d'utilisateur et l'adresse de messagerie

.

Un petit script sh peut aider

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

appelez ce script depuis votre dépôt et vous avez terminé.

  

Au départ, j'avais une version plus ancienne du code qui n'était même pas la tête de SVN. Il me manquait donc des éléments supplémentaires. Quelle est la meilleure façon de procéder?

Dans ce cas, le flux de travail de base consiste à créer un nouveau " fusionnement " branchez depuis votre branche de travail actuelle afin d'isoler l'effort de rebasement (et de résoudre tous les conflits)
Dans ce type de fusion où le delta est important, vous devez garder votre branche opérationnelle à l’abri de toutes les modifications nécessaires pour pouvoir inclure:

• le code de SVN
• le code que vous n'avez pas reçu directement du référentiel SVN.

  

Pourrai-je ultérieurement modifier mes modifications sur une branche correctement importée avec un fichier authors?

Je ne suis pas sûr mais je pense bien. Si ce n'est pas le cas, tant que vous n'avez encore rien publié, vous voudrez peut-être utiliser à nouveau un script de changement de nom branche de filtre ...

Answer 2

git-rebase dépend de l'existence d'un commit commun quelque part dans l'historique. Cela se produit également dans un seul référentiel. Il semble que vous allez vous retrouver dans une situation dans laquelle (a) le nouveau référentiel importé de git-svn est séparé du vôtre et (b) il n'y aura pas de commits communs entre les deux. Vous aurez probablement besoin de faire cela via des correctifs, mais git peut vous aider. Consultez les pages de manuel pour patch-format-git et git-am . Le premier peut générer une série de correctifs à partir d’une série de validations, et le second peut prendre cette série de correctifs et les appliquer - et tous les messages de validation et autres seront conservés.

Cela vous donnera l'occasion de résoudre votre problème user.name/email - vous pouvez simplement les modifier dans les en-têtes des correctifs et vous assurer qu'ils sont correctement définis dans le nouveau référentiel importé avant d'appliquer vos correctifs!

La meilleure façon de gérer votre point de départ obsolète ("une révision plus ancienne… qui n'était même pas la tête du SVN") sera probablement:

• mettre le référentiel SVN dans un bon état, avec toutes les modifications validées
• importez-le avec git-svn
• créer et extraire une branche d'un ancien commit à partir duquel vous avez commencé à travailler
• appliquez votre série de correctifs
• fusionner cette branche en maître, correspondant à la tête SVN actuelle

Heureusement pour moi mais moins pour vous, je n'ai jamais eu besoin d'utiliser git-svn, je ne peux donc pas répondre de manière définitive à la question de votre fichier auteurs. Cependant, si je comprends bien, le fichier authors permet de traduire les auteurs SVN en auteurs git. Si l'auteur change sur un commit git, le hachage changera. Il serait donc important de ne pas déranger cette table de traduction et de la corriger du premier coup.

Il y avait beaucoup de questions dans l'une d'elles, alors n'hésitez pas à commenter et demander plus si j'ai raté des choses.

Answer 3

Vous pouvez créer une nouvelle branche à naître avec des outils de bas niveau:

$ git symbolic-ref HEAD refs/heads/new_branch

Avec git moderne, vous pouvez rebaser toute la branche en utilisant l’option - root de "git rebase".

Cela pourrait, ou non, aider votre situation. YMMV.