Bonjour,
Je souhaite forker un projet hébergé sur github dans une instance gitlab hebergée par framasoft (framagit).
De ce que j'ai pu observer et rechercher, pour que ce fork puisse suivre les évolutions du projet original, j'ai deux possibilités:
- créer un compte github, forker le projet dans github et importer mon fork dans gitlab
- importer le projet original github dans gitlab via l'import "from any git"
La première solution m'oblige à créer un compte github, et je ne sais pas si elle offre la capacité de récupérer aisément les futurs commits du projet original.
La deuxième solution nécessite de cloner le repo gitlab en local, ajouter un remote vers le projet original sur github et créer un cron pour régulièrement récupérer les commits de github sur mon repo local puis les envoyer au repo gitlab.
Question n°1: Suis-je passé à coté d'un moyen plus simple et moins tordu pour arriver à mes fins?
Question n°2: Une fois le projet forké et associé d'une manière ou d'une autre au projet original, envoyer par email la sortie de git request-pull est-il le meilleur moyen de transmettre mes modifications pour qu'elles y soient intégrées ?
merci
# blah
Posté par mh-cbon . Évalué à -3.
Dans les deux cas de tes deux solutions tu passeras par un remote upstream,
https://help.github.com/articles/configuring-a-remote-for-a-fork/
https://help.github.com/articles/syncing-a-fork/
Je ne sais pas ce que c'est "la sortie de git request pull", j'ai dans l'idée que
man git diffest ton ami.Voir au préalable si l'upstream sera d'accord avec cette manière de procéder, et par ailleurs si tes changements l'intéresse d'une manière ou d'une autre.
Je doutes beaucoup sur cette option.
Je doutes beaucoup moins de la procédure usuelle qui consiste à faire un fetch, suivi d'un merge, éventuellement résoudre les conflits, puis générer un commit.
Sinon, c'est quoi le problème avec github au fait ?
[^] # Re: blah
Posté par Anonyme . Évalué à 2.
Donc d'après toi il n'y a pas de manière simple de gérer un fork, que ce soit dans github ou dans un repo gitlab ?
git diff génère un patch
git request-pull génère un ordre qui permet de récupérer l'ensemble des commits que l'on souhaite voir intégrer upstream
Hormis que ce soit un silo supplémentaire (propriétaire, centralisation etc…), je préférerai éviter d'avoir à gérer 3 couches:
- le fork github pour les "pull requests à la github",
- le clone gitlab pour la publication de mes contributions,
- et le clone local pour le dev)
pour participer à un projet alors que, si je passe par l'envoi d'emails contenant les git request-pull, deux semblent suffir:
- clone gitlab
- clone local
[^] # Re: blah
Posté par mh-cbon . Évalué à -6.
Peut être que ceci t’intéressera ?
https://developer.github.com/v3/pulls/#create-a-pull-request
Je pense toujours que c'est à ton upstream de te dire ce qu'il acceptera.
blah. Pourquoi pas. désaccord profond, flemme plus profonde encore.
Je ne comprends pas ce qui n'est pas simple :x
[^] # Re: blah
Posté par Anonyme . Évalué à 2.
ca reste limité à la gestion de fork au sein de github, mais c'est vrai que j'étais passé à coté de leur API web, merci.
évidemment, mais l'environnement github incite fortement à n'échanger qu'entre repos github
je peux faire la même chose avec du libre décentralisé, donc pourquoi se priver ?
reste à trouver le moyen le plus convenable d'interconnecter les deux outils.
de ce que je comprend, voila ce qui doit se faire :
1/ git clone l'upstream github sur gitlab
2/ git clone gitlab sur local
3/ git branch en local
4/ git commit en local
5/ git push de local vers gitlab
6/ git pull de github vers local puis goto 4/
7/ résolution de confit + git commit + git push
7/ git request-pull | mail upstream
simple serait:
1/ git clone l'upstream github sur gitlab
2/ git clone gitlab sur local
3/ git branch en local
4/ git commit en local
5/ git pull de gitlab vers local qui fait automatiquement et préalablement un git pull de github vers gitlab
6/ résolutio de confit + git commit
7/ git push de local vers gitlab
8/ git request-pull | mail upstram
et finalement, en l'écrivant je m'aperçois que ce je que je voudrais n'est pas plus simple.
En fait, je souhaiterai oublier l'upstream (que ce soit github ou un autre) une fois le projet cloné dans gitlab: celui-ci devrait se débrouiller pour se synchroniser tout seul avec l'upstream.
[^] # Re: blah
Posté par mh-cbon . Évalué à -6.
J'avais vu la chose ainsi, ayant aussi fait la démarche de poser les commandes,
git clone gh.com/up/stream
git remote add upstream up/stream
git remote add gh git/hub
git remote add origin frama/git
git checkout -b gh_fork --track gh/master
travail
git checkout -b mabranche --track origin/master
touch…
git commit && git push
sync
git fetch upstream
git checkout mabranche
git merge upstream/master
pr
git checkout gh_fork
git merge ma_branche
git commit -am ..
# git rebase ?
git push
Aller sur github, faire la PR, ou scripter l'api
pr par mail
git checkout mabranche
git rp | mail
Dans le cas d'une pr par mail, c'est l'upstream qui fera ton job de merge, de réconciliation et de rebase.
Alors que pour une pr plus classique, l'ui lui indiquera immédiatement si les commits sont en conflits, il n'aura qu'à faire sa petite revue de code pépère, si il a branché les hooks travis / , il aura ses résultats de CI automatiquement, et puis si il est content un coup de clic et zou c'est fini.
Comment feras tu lorsque les versions auront suffisamment divergées pour nécessiter une réconciliation manuelle ?
Si tu veux juste faire un fetch en local, alors oui, un cron suffira, mais pour intégrer les changements dans ton local, un merge sera nécessaire, donc, éventuellement, réconciliation manuelle.
décentralisé ?
[^] # Re: blah
Posté par Anonyme . Évalué à 2.
possibilité de choisir son hébergeur et s'auto-hébergé
# Cross post
Posté par Anonyme . Évalué à 2.
Ce n'était pas une bonne idée pour la lisibilité des réponses, mais comme le responsable de framagit en parlait au même moment dans un journal, j'en ai profité pour lui demander de jeter un œil à ma problématique.
Pour ceux qui passeraient par là dans le futur, sa réponse est dans ce commentaire du journal
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.