J'ai essayé plusieurs fois d'utiliser Mercurial pour mes projets perso, mais le truc ne sait rien faire de base, il faut avoir recours à des extensions : pour éditer l'historique (git rebase -i), faire des commit partiels (git add -p).
Pour l'histoire des extensions, c'est plutôt un problème de design de l'UI. Il s'agit plutôt de fonctions activées ou desactivées. Sur n'importe quelle machine tu commences par crée ton .hgrc avec ton nom de commit, et tu ajoutes les extensions que tu désires. Cela simplifie l'aide intégrée de Mercurial qui ne liste que les extensions activés, ainsi on ne se perd pas au milieu de millions de fonctionnalités. Aussi certaines "extensions" propose une réponse différente au même problème, ainsi c'est à l'utilisateur de savoir celle qu'il désire activer.
C'est un peu comme si l'on reprochait à Firefox de ne pas venir avec toutes ses extensions par défaut. Pour toi le rebase est peut-être important, mais il ne l'ai pas forcement pour moi (Simplement parce que c'est un concept un peu plus avancé de la gestion de version), ainsi ce n'est pas visible par défaut.
Pour git rebase ou les commits partiels j'accorderais une chose, c'est que le mode interactif de mercurial est limité.
Et il y a des concepts que je n'arrive pas à retrouver (le concept de dépôt distant, git remote)
git remote, c'est pas juste une fonction qui permet de changer la liste des alias des dépots distant ? Dans mercurial cela s'appelle vim et tu modifies un fichier de configuration en ajoutant ces lignes:
Là c'est juste de l'UI, mais par principe je ne suis pas fan des outils qui font des choses simples à ma place
Pour le concept de dépôt distant, je n'ai pas compris ce que c'est… Ce n'est pas juste un dépôt dans lequel il n'y a pas de copie de travail ?
Je ne me considère pas forcement comme un fanboy, et un jour je quitterais très certainement Mercurial pour Git (la victoire du plus gros), mais j'aurais quelques arguments en faveur de Mercurial (subjectif, je n'ai pas touché à git sauf pour des petits patchs tout simple depuis 4 ans)
Je passe sur le coté "je trouve cela plus simple, je n'ai jamais eu à lire le man de mercurial comparé à celui de git…" qui est hautement subjectif.
Il y a un truc que j'aime beaucoup dans Mercurial, c'est les phases. Ainsi un commit "phasé" comme étant définitif ne peut plus être rebase/amend ou autre. Cela évite le traditionnel problème de git de "Hey, mais t'a rebase sur des commits distribués à toute l'équipe… on fait quoi maintenant". Ou le traditionnel "Mais, t'as pull des changements que je voulais modifier…"
La prochaine version de Mercurial devrait commencer à amener le concept d'evolve que je trouve très propre. C'est du rebase/amend mais avec conservation de l'historique (caché) des changements détruits (et avec une relation entre les nouveaux commits rebasés et les anciens). Je m'en sers personnellement depuis quelques mois et c'est vraiment sympathique. (Je sais que git conserve les anciens changset devenu obsolète suite à un rebase/…, mais à ma connaissance git ne conserve pas l'historique et la raison de cette obsolescence).
Un fanboy de Git pourrait-il m'expliquer ce qu'il aime dans Git et pourquoi cela roxxe du poney ? Surtout niveau fonctionnalités.
[^] # Re: Je profite de ce troll
Posté par Guillaum (site web personnel) . En réponse au journal Microsoft passe à git. Évalué à 6.
Pour l'histoire des extensions, c'est plutôt un problème de design de l'UI. Il s'agit plutôt de fonctions activées ou desactivées. Sur n'importe quelle machine tu commences par crée ton .hgrc avec ton nom de commit, et tu ajoutes les extensions que tu désires. Cela simplifie l'aide intégrée de Mercurial qui ne liste que les extensions activés, ainsi on ne se perd pas au milieu de millions de fonctionnalités. Aussi certaines "extensions" propose une réponse différente au même problème, ainsi c'est à l'utilisateur de savoir celle qu'il désire activer.
C'est un peu comme si l'on reprochait à Firefox de ne pas venir avec toutes ses extensions par défaut. Pour toi le rebase est peut-être important, mais il ne l'ai pas forcement pour moi (Simplement parce que c'est un concept un peu plus avancé de la gestion de version), ainsi ce n'est pas visible par défaut.
Pour git rebase ou les commits partiels j'accorderais une chose, c'est que le mode interactif de mercurial est limité.
git remote, c'est pas juste une fonction qui permet de changer la liste des alias des dépots distant ? Dans mercurial cela s'appelle vim et tu modifies un fichier de configuration en ajoutant ces lignes:
[paths]
default=http://depot1
alias1=http://depot2
…
Là c'est juste de l'UI, mais par principe je ne suis pas fan des outils qui font des choses simples à ma place
Pour le concept de dépôt distant, je n'ai pas compris ce que c'est… Ce n'est pas juste un dépôt dans lequel il n'y a pas de copie de travail ?
Je ne me considère pas forcement comme un fanboy, et un jour je quitterais très certainement Mercurial pour Git (la victoire du plus gros), mais j'aurais quelques arguments en faveur de Mercurial (subjectif, je n'ai pas touché à git sauf pour des petits patchs tout simple depuis 4 ans)
Je passe sur le coté "je trouve cela plus simple, je n'ai jamais eu à lire le man de mercurial comparé à celui de git…" qui est hautement subjectif.
Il y a un truc que j'aime beaucoup dans Mercurial, c'est les phases. Ainsi un commit "phasé" comme étant définitif ne peut plus être rebase/amend ou autre. Cela évite le traditionnel problème de git de "Hey, mais t'a rebase sur des commits distribués à toute l'équipe… on fait quoi maintenant". Ou le traditionnel "Mais, t'as pull des changements que je voulais modifier…"
La prochaine version de Mercurial devrait commencer à amener le concept d'evolve que je trouve très propre. C'est du rebase/amend mais avec conservation de l'historique (caché) des changements détruits (et avec une relation entre les nouveaux commits rebasés et les anciens). Je m'en sers personnellement depuis quelques mois et c'est vraiment sympathique. (Je sais que git conserve les anciens changset devenu obsolète suite à un rebase/…, mais à ma connaissance git ne conserve pas l'historique et la raison de cette obsolescence).
Un fanboy de Git pourrait-il m'expliquer ce qu'il aime dans Git et pourquoi cela roxxe du poney ? Surtout niveau fonctionnalités.