2009-04-02 9 views
85

Existe-t-il un moyen d'obtenir un patch créé avec git format-patch pour qu'il soit compatible svn afin de pouvoir le soumettre à un repo svn?Git format-patch pour être compatible svn?

Je travaille sur svn repo sur github et je souhaite soumettre mes modifications au rapport principal. J'ai besoin de créer un patch pour faire cela, mais le patch ne peut pas être appliqué depuis des formats git qui se corrigent différemment de svn. Y a-t-il un secret que je n'ai pas encore découvert? Bien qu'il n'existe actuellement aucun script ni aucune méthode git native pour ce faire, j'ai réussi à trouver un post de plus tôt cette année sur la façon de l'accomplir manuellement. J'ai suivi les instructions et j'ai réussi à faire fonctionner mes patchs git avec svn.

Si quelqu'un pouvait écrire un script pour accomplir cela et contribuer au projet git, tout le monde serait très apprécié.

http://kerneltrap.org/mailarchive/git/2008/1/15/570308/thread#mid-570308

+0

Je ne peux pas le faire fonctionner ... pourriez-vous poster toutes les étapes nécessaires? Merci! –

+1

Salut Anthony. Souhaitez-vous envisager de changer la réponse acceptée à Nicholas? –

+0

Je suis d'accord avec la suggestion de Simon, la réponse de Nicholas Smith étant acceptée, tout le monde en profitera, car c'est beaucoup plus pratique. – Albireo

Répondre

74

Je dois toujours à Google cela, mais la façon dont j'ai trouvé que cela fonctionne parfaitement (pour moi) est:

  • Créer le correctif avec git diff --no-prefix master..branch > somefile.diff, la partie principale et la partie de branche sont facultatives, cela dépend de la manière dont vous souhaitez obtenir vos différences.
  • Envoyez-le partout et appliquez avec patch -p0 < somefile.diff.

Cela semble toujours fonctionner correctement pour moi et semble être la méthode la plus simple que j'ai rencontrée.

+0

Cela a fonctionné pour moi, merci –

+1

Ceci est la manière canonique de générer un correctif compatible SVN avec Git, il doit être marqué comme la réponse – mloskot

+0

'--no-pager' n'est plus une option pour' git diff'. – naught101

3

Il est en effet un feature request début 2008

Linus Torvalds dit à l'époque:

Je dirais donc que vous avez besoin quelque chose de plus fort pour dire « ne pas faire git diff ", et cela devrait également interdire la détection de renommer au minimum.
Très franchement, n'importe quel programme qui est tellement stupide de ne pas accepter les patchs git actuels (par exemple TortoiseSVN), alors nous ne devrions pas simplement désactiver la partie la plus triviale de celui-ci. Nous devrions nous assurer que nous n'autorisons pas des extensions plutôt importantes:
même si ToirtoiseSVN les ignore, si les ignorer signifie qu'il ne comprend pas le diff, il ne devrait pas être autorisé du tout.

Ce peut être pourquoi

git-format-patch: add --no-binary to omit binary changes in the patch. 

a été introduit dans Git1.5.6 en mai/Juillet 2008 (je ne l'ai pas testé si)

11

SVN peut probablement pas comprendre la sortie de git diff -p, mais vous pouvez recourir à la force brute:

  1. Faire deux clones de votre repo
  2. Dans un clone, vérifiez vos dernières nouveautés
  3. Dans l'autre clone, vérifiez tout ce qui est équivalent au svn amont. Si vous avez planifié à l'avance, vous avez une copie de svn en amont sur sa propre branche, ou vous avez étiqueté la dernière version de svn. Si vous n'avez pas planifié d'avance, utilisez la date ou gitk pour trouver le hachage git SHA1 qui se rapproche le plus de l'état svn.
  4. Calculez maintenant un réel correctif en exécutant diff -r sur les deux clones.
+12

Ou suivez simplement le conseil de @ Nicholas-smith et exécutez 'git diff --no-prefix> somefile.diff' dans votre repo git et envoyez-le à n'importe quel utilisateur svn pour qu'il applique le patch avec' patch -p0 DavidG

10

La version de Subversion < 1.6 n'a pas de support de correctif. Il semble que Subversion 1.7 permettra d'appliquer des correctifs et les extensions git/hg de diff unifiée sont sur notre liste TODO.

17

Voici un script d'aide pour faire une diff contre la dernière svn et changeset commettras donné: http://www.mail-archive.com/[email protected]/msg00864.html

#!/bin/sh 
# 
# git-svn-diff 
# Generate an SVN-compatible diff against the tip of the tracking branch 
TRACKING_BRANCH=`git config --get svn-remote.svn.fetch | sed -e 's/.*:refs\/remotes\///'` 
REV=`git svn find-rev $(git rev-list --date-order --max-count=1 $TRACKING_BRANCH)` 
git diff --no-prefix $(git rev-list --date-order --max-count=1 $TRACKING_BRANCH) $* | 
sed -e "s/^+++ .*/& (working copy)/" -e "s/^--- .*/& (revision $REV)/" \ 
-e "s/^diff --git [^[:space:]]*/Index:/" \ 
-e "s/^index.*/===================================================================/" 
+0

Ceci est très utile - merci! – Avi

+1

J'ai trouvé que la valeur REV est incorrecte si vous ne travaillez pas avec la dernière révision svn. Je l'ai corrigé pour utiliser 'git svn info' à la place: ' REV = \ 'git svn info | grep 'Dernière modification Rev:' | sed -E 's/^.*: ([[: chiffre:]] *)/\ 1 /' \ '' –

+4

L'origine de cet extrait semble provenir de: https://gist.github.com/44537 –

0

Assurez-vous que vos changements sont engagés et rebasées au-dessus de votre branche git locale, de course bash git:

git show --pretty >> myChangesFile.patch

0

La réponse acceptée fourni par Nicholas fonctionne bien, sauf quand a) des fichiers binaires existent dans le diff ou b) vous travaillez dans Windows Git et avez des répertoires avec des espaces. Pour résoudre ce problème, j'ai dû ajouter une commande git diff imbriquée pour ignorer les binaires et la commande sed pour échapper aux espaces. Il est un peu fastidieux à écrire, donc je créé un alias:

[alias] 
svnpatch = "!f() { git diff --name-only --no-prefix master...$1 | grep -Ev \"\\.sdf|\\.Doc|\\.dll|\\.zip|\\.exe\" | sed 's_\\s_\\\\\\\\ _g' | xargs git diff --no-prefix master...$1 > $1.patch; echo "Created $1.patch"; }; f" 

Si vous tapez alors:

git svnpatch Feature123 

... un fichier patch Feature123.patch sera créé avec les différences entre la fusion base de la branche principale et de la branche Feature123.

Questions connexes