Forum Programmation.autre [Résolu] Comment gérer le fork d'un projet github dans une instance gitlab (framagit) ?

Posté par . Licence CC by-sa
Tags :
3
20
juin
2016

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 . É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/

    envoyer par email la sortie de git request-pull

    Je ne sais pas ce que c'est "la sortie de git request pull", j'ai dans l'idée que man git diff est 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.

    créer un cron

    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 . É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 ?

      Je ne sais pas ce que c'est "la sortie de git request pull", j'ai dans l'idée que man git diff est ton ami.

      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

      Sinon, c'est quoi le problème avec github au fait ?

      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 . É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.

        Hormis que ce soit un silo supplémentaire (propriétaire, centralisation etc…),

        blah. Pourquoi pas. désaccord profond, flemme plus profonde encore.

        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 ?

        Je ne comprends pas ce qui n'est pas simple :x

        • [^] # Re: blah

          Posté par . Évalué à 2.

          Peut être que ceci t’intéressera ?
          https://developer.github.com/v3/pulls/#create-a-pull-request

          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.

          Je pense toujours que c'est à ton upstream de te dire ce qu'il acceptera.

          évidemment, mais l'environnement github incite fortement à n'échanger qu'entre repos github

          blah. Pourquoi pas. désaccord profond, flemme plus profonde encore.

          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.

          Je ne comprends pas ce qui n'est pas simple :x

          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 . É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.

            celui-ci devrait se débrouiller pour se synchroniser tout seul avec l'upstream.

            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.

            je peux faire la même chose avec du libre décentralisé

            décentralisé ?

            • [^] # Re: blah

              Posté par . Évalué à 2.

              décentralisé ?

              possibilité de choisir son hébergeur et s'auto-hébergé

  • # Cross post

    Posté par . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.