> enregistrer seulement un changement dans un fichier et pas forcément tous les changements d'un fichier.
git permet aussi de commiter des "patch hunks" individuellement.
Dans "git gui", tu as les changements prêts à être commités à gauche, en vert, et les changement non sélectionnés pour le commit, à droite, en rouge. Dans le diff, en bas de la fenêtre, tu peux faire clic-droit -> stage hunk for commit / unstage hunk from commit.
En ligne de commande, tu as "git add -i" qui fait ça, et permet même de couper un "patch hunk" en morceaux. (attention, git add ne fait pas ce que la plupart des autres XXX add font : il ajoute un changement - par défaut, un fichier - au commit qui se prépare).
Mais attention, il faut se méfier des commits selectifs. Quand on fait ce genre de trucs, on commite quelque chose qui n'a probablement jamais existé sur le disque, et donc, qui n'a jamais été testé.
> J'aime la simplicité "un dépot, une seule branche".
Rien ne t'empêche d'utiliser git et mercurial de cette façon. Tu n'as pas besoin de savoir qu'il y a la possibilité d'avoir plusieurs branches dans le même repository pour les utiliser.
> De plus, je ne me suis pas encore heurté de manière bloquante aux problèmes connus de darcs
J'ai utilisé un peu Darcs, j'ai trouvé l'interface utilisateur bien foutue, claire.
Par contre, je ne l'ai pas choisi pour plusieurs raisons :
* Les performances. Pour les projets que je gère, c'est pas un vrai problème, ils sont suffisament petits, mais je veux que le gestionnaire de version que j'utilise puisse passer à l'échelle, pouvoir utiliser la même chose pour moi que les gros projets. C'est une garantie que mes connaissances pourront être réutilisées, et une garantie de pérénité pour le projet (peu de risque que git ou Mercurial soient abandonnés du jour au lendemain vu les enjeux, alors que dieu seul sait ce qu'il se passerait si l'auteur de Darcs décidait d'arrêter de le maintenir).
* L'approche orientée patch. L'historique est une succession de patchs qui ont potentiellement été réordonnés, donc, la série de patchs ne corresponds pas forcément à une série d'états qui ont vraiment existé dans l'histoire.Résultat, tu ne peux pas revenir à un état passé de ton arbre de travail. Tu ne peux pas non plus dire « j'ai un problème avec la version XYZ, est-ce que vous l'avez aussi ». Avec git ou Mercurial, si je te dis que j'ai un problème avec la révision 2f82f760e1b263, c'est non ambigu, tous les développeurs savent de quoi je parlent (même arbre de travail, même historique).
[^] # Re: Darcs
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git et Mercurial. Évalué à 4.
git permet aussi de commiter des "patch hunks" individuellement.
Dans "git gui", tu as les changements prêts à être commités à gauche, en vert, et les changement non sélectionnés pour le commit, à droite, en rouge. Dans le diff, en bas de la fenêtre, tu peux faire clic-droit -> stage hunk for commit / unstage hunk from commit.
En ligne de commande, tu as "git add -i" qui fait ça, et permet même de couper un "patch hunk" en morceaux. (attention, git add ne fait pas ce que la plupart des autres XXX add font : il ajoute un changement - par défaut, un fichier - au commit qui se prépare).
Mais attention, il faut se méfier des commits selectifs. Quand on fait ce genre de trucs, on commite quelque chose qui n'a probablement jamais existé sur le disque, et donc, qui n'a jamais été testé.
> J'aime la simplicité "un dépot, une seule branche".
Rien ne t'empêche d'utiliser git et mercurial de cette façon. Tu n'as pas besoin de savoir qu'il y a la possibilité d'avoir plusieurs branches dans le même repository pour les utiliser.
> De plus, je ne me suis pas encore heurté de manière bloquante aux problèmes connus de darcs
J'ai utilisé un peu Darcs, j'ai trouvé l'interface utilisateur bien foutue, claire.
Par contre, je ne l'ai pas choisi pour plusieurs raisons :
* Les performances. Pour les projets que je gère, c'est pas un vrai problème, ils sont suffisament petits, mais je veux que le gestionnaire de version que j'utilise puisse passer à l'échelle, pouvoir utiliser la même chose pour moi que les gros projets. C'est une garantie que mes connaissances pourront être réutilisées, et une garantie de pérénité pour le projet (peu de risque que git ou Mercurial soient abandonnés du jour au lendemain vu les enjeux, alors que dieu seul sait ce qu'il se passerait si l'auteur de Darcs décidait d'arrêter de le maintenir).
* L'approche orientée patch. L'historique est une succession de patchs qui ont potentiellement été réordonnés, donc, la série de patchs ne corresponds pas forcément à une série d'états qui ont vraiment existé dans l'histoire.Résultat, tu ne peux pas revenir à un état passé de ton arbre de travail. Tu ne peux pas non plus dire « j'ai un problème avec la version XYZ, est-ce que vous l'avez aussi ». Avec git ou Mercurial, si je te dis que j'ai un problème avec la révision 2f82f760e1b263, c'est non ambigu, tous les développeurs savent de quoi je parlent (même arbre de travail, même historique).