1416Close
Lionel DebrouxOn the 2012-12-06 at 08:00am
Godzil: vrai, pouvoir sélectionner individuellement les changements à committer est une feature très utile de git gui.

Zerosquare: oui, je t'encourage à regarder Git smile
Tu connais déjà un CSCM (SVN), donc tu connais déjà un certain nombre de concepts, et tu verras les différences avec la philosophie DSCM... tu ne pourras vite plus t'en passer ^^
Avec Gitosis ou Gitolite (le plus récent des deux, je ne sais plus lequel c'est), il est très simple de mettre en place un serveur Git (par exemple à travers ssh).

Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.
Dans TIGCC, j'ai fait ce genre de travail à plusieurs reprises avec rien de plus que patch et diff (et le CVS ne contient que le patch résultant).

Ce que tu as fait n'est pas comparable. Comme je l'ai écrit, j'ai fait une série incrémentale et cohérente de plus d'une vingtaine de patches, pas un seul gros patch. Entre autres, rebase ré-applique les patches (et propose la résolution des conflits), update automatiquement les lignes des diffs.
Dans mon emploi actuel également, j'utilise rebase quasi-quotidiennement, parce que c'est très efficace.

Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.
Je ne vois pas le problème d'avouer qu'on a fait une erreur et de pousser un commit qui la corrige.

Le but n'est, bien évidemment, pas de cacher les erreurs aux autres membres de l'équipe, dont le chef de projet: mon collègue peut voir mes erreurs, je peux voir ses erreurs, et les autres membres de l'équipe peuvent voir nos erreurs.
Non, il y a d'autres raisons excellentes en pratique - ces raisons qui font que Linux, Wine et plein d'autres projets ne poussent vers la branche principale que des séries faites aussi correctement que possible, plutôt que du code-and-fix non bisectable. La bisection est une feature très importante de Git et Mercurial, même si, pour les projets de taille limitée, elle n'est utile que sporadiquement. Sur Linux ou Wine, il y en a tous les jours.
De toute façon, sur nombre de projets ouverts qui utilisent l'organisation efficace du travail qu'est le commit de séries aussi bisectables que possibles, les séries de patches sont postées publiquement, sur des MLs ou sur des repositories Git, et restent accessibles longtemps... bref, pour cacher ses erreurs, on repassera grin