Recherches récentes
Options de recherche
Je n'aime pas git. Et pas forcément pour les raisons mentionnées ici, qui sont toutefois parfaitement légitimes. https://roadrunnertwice.dreamwidth.org/596185.html #git #critique #modèle #réflexion
@Riduidel Pareil. Mais je n’aime pas non plus svn.
En même temps, si tu te cantonnes à faire des git add/status/commit, ça fait le job. Et je refuse d’apprendre plus de commandes.
Parce que mon taf, c’est de coder, pas d’apprendre comment fonctionne git, pour qq commits par semaine.
@elecharny @Riduidel SVN, j'en ai connu les derniers jours, c'était quand même une bombe à retardement.
Ça m'avait demander des efforts de m'adapter au modèle mental de git, j'ai jamais non plus surkiffé l'outil (même si avec https://magit.vc/ il existe une interface confortable).
Par contre, la décentralisation intrinsèque de git lui donne des propriétés vraiment désirable niveau sécurités des donnés (et facilité de mise en œuvre avec trois bouts de ficelles).
@webshinra @Riduidel En fait, le problème, ce n’est pas que git/svn soient compliqués, c’est que la façon dont on travaille en équipe est mal adapté. Quand tu te tapes des merges à foison, c’est que le travail est mal partagé.
Donc tout est une question d’organisation.
@webshinra @elecharny On reconnaît l'emacsiste ;-)
Pour ma part, refusant tout autant la ligne de commande comme "interface", je passe par Sourcetree ou Git Lens (j'ai un amour des clickodromes), et comme Emmanuel, je ne connaîs que 3/4 commandes.
@Riduidel @elecharny Hum… en général ou en particulier ?
En particulier, ben, on fait avec ce qu'on a (et une des fonctions de ces outil est la collaboration, donc l'effet de réseau compte).
En général, ça n'est pas plus hémiplégique que de «refuser» les interfaces graphiques.
En pratique, certaines tâches sont plus optimales sur l'une ou l'autre, la manipulation symbolique est généralement emportée par la CLI, par construction.
@webshinra @Riduidel Perso, j’utilise les deux. La ligne de commande parce que ça me permet de savoir ce qui se passe « en dessous », et l’UI quand je m’en fous (style, un commit bête).
Mais surtout, quand je code sous eclipse, je vais pas passer en ligne de commande pour ‘bitter’, et quand je bosse dans une console, je vais pas ouvrir source tree.
C’était la même chose avec SVN.
@elecharny @Riduidel Et puis, en tant qu'emacsistes spotted, j'ai toute une experience d'intermédiaire, via les TUI.
Je mettrais la nuance ailleurs: outils interactif ou non.
Pour découper une session de code en commits, j'ai envie d'un outil interactif (de préférence dans mon éditeur de texte), ou je stage tel snippet ou tel autre.
Pour un clone, c'est souvent plus pratique de nuancer via la CLI.
En pratique les deux experiences s'intègrent bien, ci-joint une capture de mon Nemo
@elecharny @webshinra C'est marrant, j'ai jamais réussi à utiliser le client git d'Eclipse (je crois que j'ai pas compris la blague). Par contre, la ligne de commande, ça me sert une fois par an maximum (et à chaque fois, je finis par copier la branche, cloner mes commits, et supprimer la branche)
@Riduidel @webshinra Le client git d’eclipse fonctionne comme celui de svn. Grosso-merdo, tu sélectionne les motifs à committer, et tu balances avec un message.
Après, je cherche pas à faire plus.
@Riduidel j'ai toujours comparé le passage à git au problème UX des arbres de conversation en ligne.
Les experts du domaine préfèrent un arbre récursif infini et se construisent un langage pour réfléchir sur la question. Le reste du monde souffrent de cette pureté idéologique.
Mais ça n’enlève rien à la pertinence de cet article.