GIT - Page 2

donc on oublie...

Ils ont installé ce truc au boulot… Ça fait un clone de GitHub en légèrement mois joli et probablement moins bien, mais ça fonctionne. (Je n'utilise pas vraiment GitHub à part pour parcourir des sources, donc je ne saurais pas dire)

Il savaient que GitHub existe en version entreprise et derriere un firewall (aka la societe github n'a pas acces a ce que ca stoque)

Ah tiens, je me demandais comment ça fonctionnait justement… Je connais pas les tenants et aboutissants, mais à mon avis, la raison du choix est plutôt monétaire.

De toutes façons, j'aime pas GIT et ce truc ne va pas me réconcilier avec:
La première chose qu'il te demande en te connectant à l'interface Web, c'est de créer une clé SSH. Bien sûr, la procédure est complètement merdique sur Windows. Ensuite quand tu essayes d'ajouter la clé dans l'outil, il t'envoie complètement chier.
Au final, on l'utilise avec HTTPS, et rien que ça c'est une vraie merde à configurer sur les postes (merci GIT), et je pense que personne n'a réussi ou sérieusement essayé de le configurer en SSH… :/

(Et quand tu vois le client GitHub pour Windows à côté, t'as mal au cul… C'est peut être le seul client GIT décent pour Windows en dehors de Visual Studio)

désolé mais vous êtes sans doute méga exigeant, tortoise git fait complètement le boulot, y compris avec ssh, via putty.

À ma connaissance, le seul client GIT qui fonctionne correctement sans installation de msysgit, c'est celui intégré à Visual Studio, c'est un gros point en sa faveur pour ma part: Ça marche, et c'est tout

En meme temps si tu utilise SVN, on utilise aussi généralement des clefs SSH pour éviter de taper 150000000000000000000 de fois son mot de passe pour faire un simple commit.. (et les outils fournis avec putty marchent a merveille pour ca )

Bah, TortoiseSVN sait retenir un mot de passe, heureusement

Et tortoisesvn est d'une lenteur...

Pourquoi crois-tu qu'il s'appelle comme ça ?

Oo
J'ai pas souvenir d'avoir eu de soucis à ce niveau*… Pourtant le projet que j'ai en tête est assez costaud :d

(*À part à travers une connexion internet "lente", mais alors ne parlons même pas de GIT )

./37 au taf on a pas de mot de passe. Les repos sont sur un serveur, on push via les montages réseau samba, sous le controle de nos mots de passe réseau

GC: compare avec svn en ligne de command. J'ose esperer que TortoiseSVN c'est ameliore avec le temps, mais au moment ou je l'ai teste, la difference de vitesse etait superieur a *10...

squalyl:

GoldenCrystal (./36) :
À ma connaissance, le seul client GIT qui fonctionne correctement sans installation de msysgit, c'est celui intégré à Visual Studio, c'est un gros point en sa faveur pour ma part: Ça marche, et c'est tout

Le seul ? j'utilise le client GIT de Netbeans sans aucun soucis depuis un bout de temps, couplé au système d'historique et de comparaison des sources de l'IDE c'est impeccable.

(*À part à travers une connexion internet "lente", mais alors ne parlons même pas de GIT )

Pour l'expérience que j'en ai depuis 7 ans (*), il n'y a pas photo entre Git et SVN:
* un push Git d'un commit touchant des fichiers texte (au sens large) fait habituellement quelques KBs, quelques dizaines de KBs s'il y a vraiment beaucoup de changements; la même chose avec SVN nécessite plus de round trips avec le serveur, pour ce dont je me souviens et que je peux voir chez mes collègues.
* le téléchargement de toutes les révisions du repository SVN avec SVN par rapport au clonage d'un repository Git (comparons ce qui est comparable)... n'en parlons pas
* je n'ai pas de données sur les bandes passantes nécessaires à un checkout SVN classique et à l'obtention d'un shallow clone Git de profondeur d'historique 1;
* sur la taille disque des copies de travail / clones, en revanche, j'ai des données claires... Dans mon premier boulot, du temps de SVN 1.6, un répertoire .git contenant les plus de 10K révisions du repository SVN faisait ~400 MB, moins que les répertoires .svn contenant seulement les données pour le checkout de HEAD. SVN 1.7 a significativement optimisé les WCs SVN, mais les essais que j'avais faits sur d'autres repos montraient toujours un énorme avantage pour Git. Le futur SVN 1.9 réduira l'écart avec les DSCM.

*: au boulot, 4 repositories SVN, utilisés exclusivement à travers Git, dans mes 3 boulots successifs, et un repo Git dans ce boulot depuis plus de 2 ans pour pousser des commits de test; en temps libre, historiquement, principalement des repositories SVN, utilisés avec SVN avant l'automne 2007 et Git depuis, puis des repositories Git ces derniers temps.

Sur une machine, la mise en place d'un repo Git, avec clés SSH, avait été triviale. Sous Windows, c'est probablement moins simple, comme beaucoup d'installations - mais heureusement, je n'ai jamais eu à me soucier de cette plate-forme au boulot (et je ne compte pas avoir à m'en soucier), et en temps libre, je peux cross-compiler.


Est-ce que TortoiseSVN est aussi lent quand l'intégration shell n'est pas activée ?

nous au boulot c'est simple: svn et rien d'autres, juste parce que les révisions sont numérotées. On m'a opposé un niet concerté pour git parce qu'on n'est pas capable de dire facilement si le commit b16b00b5 est arrivé avant ou apres le commit cafefade

Après avoir utilisé git je ne repasserait pas du tout sous SVN...

Rien que le fait de pouvoir faire des branches fait que je n'ai pas du tout envie de revenir sous SVN (c'est tellement pratique). Et pour dire si les commits sont arrivés avant ou après, même sans avoir github, juste un gitweb permet d'avoir la liste des commits facilement en visuel.
(Et même si c'est trop compliqué, les gens peuvent mettre la date dans le texte du commit)

Tu savais pas faire des branches sous SVN ?

Comparé à GIT, le branching sous SVN est beaucoup plus pénible.

et il faut passer par le serveur pour chaque operations..

(au pire il suffit d'utiliser les TAG sous git pour numeroter les commits importants)

En effet, le branching SVN est certes meilleur que celui de CVS, mais les DSCM font beaucoup mieux.

nous au boulot c'est simple: svn et rien d'autres, juste parce que les révisions sont numérotées. On m'a opposé un niet concerté pour git parce qu'on n'est pas capable de dire facilement si le commit b16b00b5 est arrivé avant ou apres le commit cafefade

En effet, comme l'indique Godzil, c'est trivial d'avoir des commits numérotés avec Git, grâce aux tags Git, qui sont des étiquettes atomiques et non une lourde copie figée de tout l'arbre des sources quand on fait un checkout du repository complet comme en SVN... (*)
Tes collègues n'ont pas voulu admettre que le hash SHA1 ou son préfixe réduit ne sont pas les seules formes possibles pour référencer des commits, qu'il suffit d'utiliser un tag Git 0.1 pour pouvoir ordonner "0.1-234" et "0.1-345" (qui ne sont pas moins clairs que les révisions SVN r234 et r345) ?
Moyennant d'utiliser toujours le delta entre la révision actuelle et le dernier tag Git (comportement par défaut de `git describe`), on peut aussi réaliser un ordre total sur les commits. Avec 0.2 descendant de 0.1 et 0.1-345 antérieur à 0.2, 0.2-234 est ultérieur à 0.1-345.

*: dans mon miroir du repository de mon premier boulot, que j'ai conservé puisqu'il s'agit d'un projet open source, les tags SVN, branches SVN, et autres sandbox et répertoires spéciaux (je ne pouvais pas utiliser le layout standard de SVN puisqu'on utilisait plusieurs répertoires agissant comme branches, et je crois qu'à l'époque, mes essais de spécifier plusieurs arguments branches n'avaient pas donné les résultats espérés), sont responsables de l'immense majorité des plus de 140000 fichiers dans plus 60000 de répertoires de mon checkout, représentant 5 ans après toujours presque 10% des entrées dans les tables de cette partition.

non, une numerotation humaine est faillible, et en pratique, ca ne marche pas. il y aura au moins un oubli qui va tout peter. et on ne veut pas numeroter juste quelques commits, parce que quand on teste des release candidates, on a pas envie de les tagger definitivememt.

au moins les numeros de rev svn sont incontournables, infaillibles, strictement croissants, et automatiques.

de plus l'absence de $subst$ built-in imposee theologiquement par torvalds est derangeante, chez nous c'est indispensable, ne serait ce que pour afficher le dernier auteur.

pour les revision de fichiers multiples on utilise svnrev en prebuild step et ca finit directement dans le binaire final, git ne peut pas faire ca aussi facilement.

ceci dit pour une utilisation perso il y a longtemps que je n'utilise plus svn

et on ne veut pas numeroter juste quelques commits, parce que quand on teste des release candidates, on a pas envie de les tagger definitivememt.

Justement, le fait de les tagger définitivement permet de retrouver directement la révision exacte d'une release candidate, et ça ne coûte que quelques octets.
Linux, et d'autres, utilisent plusieurs tags Git par release, et ils en ont l'air contents.

au moins les numeros de rev svn sont incontournables, infaillibles, strictement croissants, et automatiques.

D'accord avec toi. Infaillibles, strictement croissants, et automatiques, oui. Incontournables, forcément, il n'y a pas grand chose d'autre ^^
Après, si on fait un tant soit peu attention à ce qu'on fait, la sortie de `git describe` est, entre autres, strictement croissante.

de plus l'absence de $subst$ built-in imposee theologiquement par torvalds est derangeante, chez nous c'est indispensable, ne serait ce que pour afficher le dernier auteur.

Hmm... ça vous arrive souvent, d'avoir besoin de déterminer l'auteur du dernier commit sur un fichier ?
Surtout que ça ne fournit qu'une information très partielle. Si on veut vraiment retrouver qui a introduit un problème dans la base de code (en général, il porte sur un petit sous-ensemble du fichier), c'est `blame` qu'il faut utiliser, et à ce moment-là, pas de différence fonctionnelle entre SVN et Git. Bien sûr, l'un a besoin d'un accès au serveur central, et pas l'autre.

ceci dit pour une utilisation perso il y a longtemps que je n'utilise plus svn

Voilà, je pense qu'on en est pour la plupart là, nous avons laissé derrière nous les outils du passé.

Oué. M'enfin :
* SVN ne permet pas de réécrire l'histoire.
* Je me suis déjà fait des putains de frayeurs avec GIT avec un rebase qui s'est mal passé, et une perte de plus de 100 commits dans une branche ! (J'ai finalement réussi à réparer la branche, mais avec SVN j'aurai pas eu à le faire).
* SVN supporte les répertoires vides.
* SVN support la gestion de conf de fichiers binaires.

SVN ne permet pas de réécrire l'histoire.

Ca, c'est un vilain défaut. Très vite, je n'ai plus pu me passer de la réécriture d'historique intégrée de Git, pour un historique des commits plus linéaire et plus facile à bisecter. On s'en fout de tous les commits incomplets et buggés qu'on a fait lors du développement (des conneries, on en fait toujours). Si on peut réécrire pour faire un truc propre avant de diffuser, c'est une feature importante
Réécrire les branches remote sur un repository public, c'est largement considéré comme très vilain, pour des raisons en général bonnes.
Quand on n'a pas la réécriture d'historique, il faut avoir recours à plusieurs outils (quilt + SVN, par exemple) plutôt qu'un seul (Git).

Je me suis déjà fait des putains de frayeurs avec GIT avec un rebase qui s'est mal passé, et une perte de plus de 100 commits dans une branche ! (J'ai finalement réussi à réparer la branche, mais avec SVN j'aurai pas eu à le faire).

Forcément, traditionnellement, SVN ne sait pas rebaser, et de plus, son merge est moins malin que celui de Git, même s'il est amélioré au fil du temps ^^
Mais sinon, je compatis, bien que je ne me sois pas trouvé dans la situation d'avoir à faire ce genre de réparations. Je n'ai pas non plus eu des branches aussi longues par rapport à une branche principale qui évolue en parallèle, seulement jusqu'à ~25 commits.

SVN supporte les répertoires vides.

C'est un fait, mais le contournement de cette absence de support par Git (qui s'explique par des raisons semi-techniques) n'est quand même pas difficile
Le fichier placeholder peut d'ailleurs très bien être un .gitignore, comme dit plus haut.

SVN support la gestion de conf de fichiers binaires.

On peut bien entendu mettre des fichiers binaires dans Git, mais c'est connu que Git (seul) n'est pas le plus doué pour leur gestion, en effet.

Lionel Debroux (./55) :
Ca, c'est un vilain défaut. Très vite, je n'ai plus pu me passer de la réécriture d'historique intégrée de Git, pour un historique des commits plus linéaire et plus facile à bisecter. On s'en fout de tous les commits incomplets et buggés qu'on a fait lors du développement (des conneries, on en fait toujours). Si on peut réécrire pour faire un truc propre avant de diffuser, c'est une feature importante
Réécrire les branches remote sur un repository public, c'est largement considéré comme très vilain, pour des raisons en général bonnes.Quand on n'a pas la réécriture d'historique, il faut avoir recours à plusieurs outils (quilt + SVN, par exemple) plutôt qu'un seul (Git).

Pour moi, réécrire l'histoire reste la pire cochonnerie qu'un gestionnaire de version peut faire (en fait, GIT ne réécrit pas l'historique des commits mais écrit un nouvel historique des modifications à partir de la racine, puis oublie où se trouve l'ancienne histoire - je pense qu'on doit pouvoir retrouver l'histoire avant rebase en cherchant bien).

Lionel Debroux (./55) :
On peut bien entendu mettre des fichiers binaires dans Git, mais c'est connu que Git (seul) n'est pas le plus doué pour leur gestion, en effet.

On peut les mettre, mais on peut pas faire leur gestion de conf avec.

Tant qu'on n'a pas fait de gc, en effet, on peut retrouver les vieux commits. Mais ça a rarement de l'intérêt pour moi. En général, on se fout des commits incomplets / buggés / de test qu'on a faits au cours du temps.
J'utilise la fonctionnalité connue comme réécriture d'historique (même si techniquement elle n'en est pas, nous sommes d'accord) locale quotidiennement, et la réécriture d'historique distante forcée (sur un repo que je suis le seul à utiliser, je vous rassure ) quasi-quotidiennement.

Dans l'historique publié, la bisectabilité est utile, même dans les petits projets (`git bisect` m'a déjà aidé plusieurs fois au boulot), ne parlons pas du kernel Linux où elle est absolument indispensable. Or, le commit-and-fix nuit gravement à cette bisectabilité, alors que la réécriture d'historique est un des principaux outils de cette bisectabilité.