Tu parles soudainement d'utilisateur débile alors qu'on parle de dev. Un SCM c'est l'outil de base d'un dev.
Un dev n'est pas un admin. Moi en tant que dev, administrer ça me fait chier. Et je pense que je ne suis pas le seul.
Un SCM c'est l'outil de base d'un dev.
Non, c'est un éditeur de texte. Mais passons.
Si ton seul argument au fait que SVN soit chiant à mettre en place, c'est "un SCM c'est l'outil de base d'un dev", c'est comme dire que tu doit apprendre à utiliser ed parce que un éditeur de texte c'est l'outil de base d'un dev.
Tu donnes des avantages à git qui n'existent pas. Ton coup de *.pyc il existe aussi avec git. git init . && git add . te donne exactement la même chose qu'un svn import et les solutions sont exactement les mêmes.
À la différence que les gens qui utilisent git add . ont soit une grosse arborescence bien compliquée (pas notre cas), soit sont des utilisateurs de SVN, et que de toute façon, git add . ne commite pas, tu peux toujours enlever les fichiers que tu n'aime pas avant de commiter.
Il ne doit surtout pas lire la doc ni comprendre un bête svnadmin. Pourquoi il comprendrait git init et la structure de git ?
Ou j'ai dit qu'il ne doit pas lire la doc ? je dis que la doc de svnadmin est plus prévue pour des administrateurs que la doc de git init ou svn. Suffit de commencer à la lire pour le voir.
Et puis la structure de git, tu n'en a pas besoin pour git add && git commit. Tu en à besoin quand tu commence à brancher dans tout les sens, ou si tu travaille avec un dépôt distant qui branche dans tout les sens.
Il est tellment bête qu'il ne comprend que vaguement co/ci/log par contre il est capable de faire des rebase interactifs & co et d'en comprendre le conséquences. Comment dire ?
Faire un rebase interactif ça n'est pas aussi difficile à expliquer que ce que tu crois, même si la doc de git rebase est nulle. Et git te guide bien sur ce que tu peux/doit faire à chaque étape (oui, c'est les messages super-verbeux qui te font chier quand tu les connais par cœur). En comprendre les conséquences, ça ne s'applique pas tant que tu n'a pas publié, et c'est expliqué dans la doc mal foutue.
[^] # Re: Bon
Posté par Batchyx . En réponse au journal L'angoisse du programmeur. Évalué à 1.
Un dev n'est pas un admin. Moi en tant que dev, administrer ça me fait chier. Et je pense que je ne suis pas le seul.
Non, c'est un éditeur de texte. Mais passons.
Si ton seul argument au fait que SVN soit chiant à mettre en place, c'est "un SCM c'est l'outil de base d'un dev", c'est comme dire que tu doit apprendre à utiliser
edparce que un éditeur de texte c'est l'outil de base d'un dev.À la différence que les gens qui utilisent
git add .ont soit une grosse arborescence bien compliquée (pas notre cas), soit sont des utilisateurs de SVN, et que de toute façon,git add .ne commite pas, tu peux toujours enlever les fichiers que tu n'aime pas avant de commiter.Ou j'ai dit qu'il ne doit pas lire la doc ? je dis que la doc de svnadmin est plus prévue pour des administrateurs que la doc de
git initousvn. Suffit de commencer à la lire pour le voir.Et puis la structure de git, tu n'en a pas besoin pour
git add && git commit. Tu en à besoin quand tu commence à brancher dans tout les sens, ou si tu travaille avec un dépôt distant qui branche dans tout les sens.Faire un rebase interactif ça n'est pas aussi difficile à expliquer que ce que tu crois, même si la doc de
git rebaseest nulle. Et git te guide bien sur ce que tu peux/doit faire à chaque étape (oui, c'est les messages super-verbeux qui te font chier quand tu les connais par cœur). En comprendre les conséquences, ça ne s'applique pas tant que tu n'a pas publié, et c'est expliqué dans la doc mal foutue.