• [^] # Re: Popularité

    Posté par . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.

    Merci pour ces éclaircissements.

    Ma réflexion ne portait pas sur le fait que git communique ou non avec les autres dépôts qu'au travers des synchronisations. Je sais que les commandes dont tu parles existent mais elles n'ont pas la même finalité.
    Ma remarque portait plutôt sur le fait que certains pensent que le hg incoming est un plus par rapport à Git alors qu'en fait cette commande vient juste pour rendre cohérente la conception de Hg.

    Hg n'intègre pas de part sa conception, le fait de séparer la synchronisation des dépôts de l'intégration avec son code (merge).
    Ceci à l'avantage de la simplicité dans certains cas mais peut s'avérer plus contraignants dans d'autres. Du coup cette commande pour inspecter les commits du dépôt distant est indispensable pour le bon fonctionnement de hg alors qu'elle ne l'est pas pour Git.

    A l'inverse, le modèle de git est plus complexe à maîtriser. Combien de nouveaux venus sur Git qui ne comprennent pas la différence entre un git pull et un git fetch merge|rebase réclament cette commande ou sont rassurés de pouvoir browser le serveur avant de se synchroniser.

    Une partie de la complexité de Git provient aussi du fait que ce qui est implicite pour Hg a dû faire l'objet de
    beaucoup de contorsions et de balbutiements pour automatiser de manière acceptable le pull et faire le match entre l'upstream et le local alors que pour Hg ... c'est juste la même branche.
    En témoigne par exemple les évolutions successives sur les set-upstream, la config des refspecs et plein d'autres paramètres qu'il faut bien souvent tuner. Ou comment les git users se transforment en bookmarkeurs de Stackoverflow compulsifs:
    http://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-upstream-all-the-time
    http://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch
    ...