Pourquoi les DVCS semblent-ils tous avoir une phobie irrationnelle de changements non engagés?

Venant d'un arrière-plan SVN, l'une des choses les plus difficiles à s'habituer lorsque vous travaillez avec des systèmes DVCS est la façon dont ils semblent tous considérer tout changement non engagé, comme une bombe à retardement.

Dans Mercurial, si vous essayez de récupérer des modifications et que vous avez des modifications non validées dans votre copie de travail, vous devez sauter à travers des cadres pour obtenir simplement la fusion des modifications entrantes. Essayez de changer de branche? Cela vous obligera à tout ranger et ensuite vous devrez immédiatement tout ranger à l'autre bout. (SVN n'a aucun problème avec l'un ou l'autre de ces scénarios.)

Git est à peu près la même chose. Je travaille côte à côte avec un autre développeur sur un projet, et j'ai juste essayé de choisir l'un de ses commits dans ma fourchette. Il a refusé de me laisser car j'ai des modifications non validées dans ma copie de travail, sur des fichiers complètement différents de ceux modifiés dans son commit. Il n'y a même pas d'option de fusion; apparemment, je dois d'abord cacher mes modifications!

Si une personne devait traiter quelque chose de complètement inoffensif avec une extrême prudence, je l'appellerais une "phobie", une peur irrationnelle qui devrait être considérée comme un trouble mental. Mais Git et Mercurial ont été conçus par deux équipes différentes de développeurs intelligents et rationnels, je dois donc me demander s'ils savent quelque chose que je ne connais pas.

Y a-t-il une raison technique qui justifie cette attitude vis-à-vis des changements non engagés? Et si oui, pourquoi le problème en question ne semble-t-il exister que sur les DVCS?

version-control dvcs

— Mason Wheeler
source

N'est-ce pas tout l'intérêt de ces choses que vous pouvez vérifier trivialement dans votre succursale locale? La fusion avec l'autre développeur devient alors une fusion réelle plutôt que d'essayer de résoudre trois sources (votre version, vos modifications, leur version). Je ne suis cependant pas un expert dans ce domaine, donc peut-être hors de la base.

— Telastyn

Je suis d'accord avec Telastyn. Je pense que la raison pour laquelle vous rencontrez des restrictions apparemment irrationnelles est que vous n'utilisez pas Git de manière idiomatique. L'une des principales forces de Git est que vous pouvez vous engager localement. Si je devais fusionner le code de quelqu'un d'autre dans ma copie de travail, je ferais sûrement un sacré engagement local en premier. Les commits locaux sont bon marché, faciles à nettoyer et constituent un filet de sécurité incroyable. Je ne suis pas surpris que les flux de travail Git tournent autour de lui (et par conséquent, les avertissements et les restrictions supposent que vous préférez valider que travailler sur des fichiers non validés).

— MetaFight du

@Telastyn: Non, vous ne pouvez pas, car un enregistrement - même dans votre branche locale - nécessite une raison de validation et crée un enregistrement dans l'historique. Donc, si vous archivez quelque chose qui n'était pas encore prêt à être validé, éventuellement lorsque vous êtes prêt à envoyer des modifications au référentiel distant, cet historique sera là, sauf si vous effectuez des opérations supplémentaires pour réécrire l'historique. Cela ne correspond à aucune définition de «trivial» que je reconnais, et cela me semble être une complexité supplémentaire sans aucun avantage articulable.

— Mason Wheeler

Vraiment? "XYZ stabilisé pour la fusion du principal" est un fardeau, ou va à une histoire trop polie?

— Telastyn

Souhaitez-vous soumettre un article pour publication sans au moins éditer pour plus de clarté? Ensuite, ne soumettez pas votre première version de commit pour publication. Faites grand plaisir à tous ceux qui liront votre code: revenez en arrière et produisez la série de commit que vous auriez écrite si vous aviez eu la prévoyance de le faire de cette façon en premier lieu. Le rebase interactif n'est pas difficile ..

— jthill

Réponses:

Dans le monde DVCS, les commits sont bon marché et l'histoire est modifiable. Le WIP peut être aussi "sale" que vous le souhaitez: et je ne vois aucune raison de "supprimer mon état actuel dans le jeu de modifications pour le stockage"
L'histoire de SVN est linéaire, donc - vous devez fusionner vos brouillons avec les changements des nouvelles révisions. DVCS utilise (nativement) DAG, et une tête supplémentaire (commit + pull + up) pour l'historique divergé est plus sûre que de fusionner à la volée le répertoire de travail modifié avec des changements externes récupérés
Lorsque vous basculez (vers un nœud ) WC modifié dans Subversion, vous vous débarrassez d'une fusion supplémentaire potentielle (contrairement à "commit to old" - "switch" - "merge 1 rev. Range") ... et nous savons: merges dans SVN ne sont pas le côté parfait de l'outil, alors que ce n'est pas du tout un problème pour les DVCS

Ce n'est pas une phobie, c'est une application (parfois sévère) du respect des bonnes manières "s'engager souvent" (les utilisateurs SVN ont parfois peur de ce style)

Et, enfin, hg qnew|qpop|qpushc'est un petit prix juste pour la propreté et l'ordre

— Blaireau paresseux
source

Lorsque vous fusionnez ou sélectionnez git, vous créez immédiatement un commit. L'opération n'est pas terminée tant que cette validation n'est pas terminée et ne fait pas partie de l'historique.

Maintenant, que se passerait-il si giton vous permettait de masquer vos modifications non validées dans votre répertoire de travail? Vous auriez (plus ou moins) du mal à faire la différence entre les changements / conflits de fusion dont vous avez besoin pour gérer la fusion / sélection, et les changements que vous avez introduits vous-même. De plus, il vous serait presque impossible de tester ce que vous commettez réellement.

Ainsi, forcer un répertoire de travail propre pour les situations de fusion aide à garder les choses simples et gérables. Après tout, tout ce que vous devez faire est de ranger vos modifications non validées avant la fusion et de les décompresser ensuite. Notez que dans le workflow

git stash
git pull
git stash pop

vous avez deux (!) opérations de fusion. Un qui fusionne votre dernier commit avec les modifications entrantes, et un qui fusionne vos modifications non validées avec le commit de fusion résultant. De cette façon, vous n'avez besoin que de fusionner deux choses en une seule, en évitant la confusion qui résulterait de la tentative de fusionner trois choses en une en une seule opération tout en essayant d'ignorer ces trois choses. Le git stash/ git stash poprend facile et explicite que vous ignorez vos modifications non validées pour la fusion.

— cmaster - réintégrer monica
source