la commande "revert" permet d'annuler les modifs en cours
On récemment ajouté la commande "restore" qui est arrivé pour pallier au fait que revert se faisant avec "checkout --" mais même là, il va falloir du temps avec que tout le monde se l'approprie.
Bah voilà encore un exemple, revert (en tout cas sa version SVN si mes souvenirs sont bons) ne se fait pas avec ckeckout -- (au passage le "--" n'est vraiment utile que pour des fichiers que tu n'as même plus dans ton tree) mais avec reset. Enfin, en fait, les deux si on veut. Parce que revert n'a pas d'équivalent exact puisque git a une staging area et selon que tu veux "finalement ne plus commit mais garder le changement" ou "remettre comme sur l'index"...
Alors oui c'est de la complexité en plus mais pour quoi ? Bah pour éviter le merdier infâme de SVN de "si tu veux commit ton travail en cours tu ne dois avoir en diff que ce que tu veux commit et tout sera commit". L'un dans l'autre, je préfère devoir apprendre git que garder svn.
aidé des collègues à récupérer des changements presque perdus tellement Git est complexe à utiliser.
Ah oui ça c'est ma spécialité en entreprise depuis 10 ans. 99% du temps parce que Monsieur Dame la Diva Dév. n'a pas daigné lire la sortie standard puis a lancé au pif une vingtaine de commandes trouvées au hasard sur internet (je le sais, je dois remonter dans l'historique shell pour comprendre comment ils ont bien pu merder autant).
On pourra arguer qu'un outil doit être "utilisable". Oui, et on peut arguer qu'un dev pas capable de lire la sortie standard de son outil (je ne parle pas de la comprendre ; je dis bien pas capable de la lire) n'est pas un dev.
J'ai utilisé anecdotiquement hg. Bah j'ai eu du mal, j'ai pesté parce que je n'arrivais pas si bien qu'avec git (et j'ai rigolé quand j'ai lu le man ; y a genre 2 fois plus de commandes haut-niveau que dans git, et chacune (à première lecture en tout cas) redondante avec 1 ou 2 autres, alors quand après on me parle des commandes absconses de git...) mais je me suis pas dit que c'était un outil naze, juste que je le maitrise pas.
[^] # Re: Au revoir mercurial
Posté par Sufflope (site web personnel) . En réponse au journal Bitbucket abandonne les utilisateurs de Mercurial. Évalué à 3. Dernière modification le 16 janvier 2020 à 22:49.
Bah voilà encore un exemple, revert (en tout cas sa version SVN si mes souvenirs sont bons) ne se fait pas avec ckeckout -- (au passage le "--" n'est vraiment utile que pour des fichiers que tu n'as même plus dans ton tree) mais avec reset. Enfin, en fait, les deux si on veut. Parce que revert n'a pas d'équivalent exact puisque git a une staging area et selon que tu veux "finalement ne plus commit mais garder le changement" ou "remettre comme sur l'index"...
Alors oui c'est de la complexité en plus mais pour quoi ? Bah pour éviter le merdier infâme de SVN de "si tu veux commit ton travail en cours tu ne dois avoir en diff que ce que tu veux commit et tout sera commit". L'un dans l'autre, je préfère devoir apprendre git que garder svn.
Ah oui ça c'est ma spécialité en entreprise depuis 10 ans. 99% du temps parce que Monsieur Dame la Diva Dév. n'a pas daigné lire la sortie standard puis a lancé au pif une vingtaine de commandes trouvées au hasard sur internet (je le sais, je dois remonter dans l'historique shell pour comprendre comment ils ont bien pu merder autant).
On pourra arguer qu'un outil doit être "utilisable". Oui, et on peut arguer qu'un dev pas capable de lire la sortie standard de son outil (je ne parle pas de la comprendre ; je dis bien pas capable de la lire) n'est pas un dev.
J'ai utilisé anecdotiquement hg. Bah j'ai eu du mal, j'ai pesté parce que je n'arrivais pas si bien qu'avec git (et j'ai rigolé quand j'ai lu le man ; y a genre 2 fois plus de commandes haut-niveau que dans git, et chacune (à première lecture en tout cas) redondante avec 1 ou 2 autres, alors quand après on me parle des commandes absconses de git...) mais je me suis pas dit que c'était un outil naze, juste que je le maitrise pas.