Discussion :

[wd_newbie]

Bonjour,

Je me tourne vers vous, car j'essaie de voir si GIT / Github correspond bien à mon besoin, soit :

Je développer des applications, et pour des raisons d'organisation personnelle, je travaille sur 3 machines différentes

- un portable sur mon lieu de travail ( qui doit rester sur place)
- un ordinateur de bureau à mon domicile
- un autre portable qui me suit dans mes déplacements

Le but est de pouvoir travailler à tout moment avec les dernières versions des fichiers, que je soit au travail, en déplacement ou a domicile

Je me suis dit que je pouvait mettre ce code dans un dépot git et faire des commit / récupération depuis le dépôt ...

Mais en gros ce ne serait pas vraiment du versionnage (quoique c'est un plus) , mais plus de la synchro que je recherche
Je ne pense pas partager pour le moment ce code et je ne voudrais pas "polluer" github avec ce genre d'utilisation ?

Ou avez-vous une meilleurs idée pour l'utilisation que je recherche

Merci d'avance

[Obsidian]

Bonjour,

Effectivement, c'est surtout de la synchronisation de fichiers qu'il te faut, mais il y a d'autres cas de figure à prendre en compte :

• Quel système d'exploitation utilises-tu au quotidien, et sur tes trois machines ?
• Quelle attitude doit-on adopter lorsque les dépôts diffèrent ? Pas seulement lorsqu'il manque des fichiers d'un côté ou de l'autre, mais également lorsque leur contenu diffère ?

Première chose : si tu as accès au réseau en permanence, le plus simple à mettre en place reste un dépôt partagé sur un serveur quelconque.

Si tu travailles avec Unix/Linux, il existe déjà rsync qui sert à ça. C'est utile par exemple si c'est un site web que tu mets à jour, en conservant ta copie locale comme « officielle ». Dans ce cas là, tu optes pour le mirroring et l'outil se débrouille pour que le site distant soit la copie conforme du local, en effaçant des fichiers si il le faut et en écrasant ceux qui diffèrent avec la version locale même si elle est plus ancienne… sauf si tu lui demandes justement de ne pas le faire ! Dans ce cas de figure, même sans contrôle de version, tu bénéficies du côté incrémental de la chose, qui ne modifiera que ce qui a besoin de l'être.

Si en revanche, chaque version de tes fichiers compte, que ce soit au bureau ou sur tes portables et qu'en cas d'incohérence, il faille pouvoir les confronter pour arbitrage, alors oui : il te faut un logiciel de versioning. Git étant alors un très bon choix, en particulier parce qu'il est décentralisé et que tu ne seras pas dépendant techniquement d'un serveur en particulier.

[wd_newbie]

Merci pour la réponse.

Pour les OS, je suis uniquement sur Windows, sur les 3 machines.
Le site web "officiel" est lui sur Linux, chez un hébergeur. Pour ce qui est du déploiement même, ce n'est pas un souci.
Je me suis fait un petit utilitaire qui liste tous les fichiers modifiés après le dernier déploiement et qui le pousse vers le serveur via FTP.
Cette partie fonctionne bien.

C'est juste que j'aimerais bien avoir toujours mes fichiers à jour dans mes machine.

Pour certains développements, je dois utiliser Windev (oui, je sais… ) , mais je dois avouer que d'utiliser leur système de gestion de source est pas mal :
- j'ouvre un projet, il me télécharge les dernières modifs depuis mon serveur utilisé à cet effet ;
- j'enregistre le projet, les modifications sont poussées vers le serveur de gestion de code.

C'est cette facilité que j'aimerais retrouver, mais pour mes projets PHP…

Même l'idée d'héberger un dépôt Git sur mon serveur me va bien, mais je me perds un peu dans les explications que je trouve sur le web…

[esperanto]

Je vais distinguer deux choses ici: le logiciel de synchronisation d'une part, le lieu de stockage d'autre part.

Pour le premier point, la question se pose entre Git et des outils ne faisant que la syncronisation, comme rsync cité plus haut.
Vu que tu fais du développement, autant utiliser un logiciel de version, ils sont conçus pour ça: par exemple tôt ou tard tu auras une version stable de ton logiciel et des nouveaux développements avec risque d'introduction de nouveaux bugs. Même si tu es le seul utilisateur de ton logiciel, ça peut valoir le coup d'avoir une branche de développement et une de production.
Une synchronisation simple, type rsync, consommait autrefois moins de puissance de calcul et de bande passante qu'un gestionnaire de versions. Mais avec les outils récents comme Git, il ne faut pas oublier que tu as localement ur chaque machine une copie intégrale du dépôt distant, du coup lors d'une synchronisation il ne transmet que les différences et pas les fichiers complets ce qui prend moins de temps.
Un bémol cependant: ça ne marche qu'avec les fichiers plein texte. Si c'est pour manipuler tes sources, même en Windev (à moins que Windev utilise un encodage que j'ignore) c'est très bien, mais évite quand même de mettre des binaires dans Git, il n'est clairement pas conçu pour ça.
Si tu as principalement des binaires, mieux vaut revenir à rsync : de toute façon calculer les différences entre binaires est peu efficace et il n'existe aucun moyen générique de faire une fusion (c'est à dire combiner les modifications faites de chaque côté) si tu as modifié des binaires sur plusieurs de tes machines de façon différente. N'oublie pas, à ce titre, que si HTML ou XML peuvent être considérés comme textuels (mais s'il y a peu de sauts de ligne ils deviennent comme des binaires) un format comme ODF (OpenOffice) est quand même un format binaire, même s'il contient du texte.

Pour le lieu de stockage ensuite. L'avantage de GitHub, c'est que c'est vite fait de créer un compte et de mettre quelque chose dessus.
Par contre seuls les dépôts publics sont gratuits. Tu dois donc te demander si ça te pose ou non un problème que ton code puisse potentiellement être lisible par n'importe qui. Même si beaucoup de dépôts publics n'ont probablement jamais été visités, on ne peut pas exclure qu'ils le soient. Au minimum, mets une licence pour préciser ce qu'il est autorisé de faire avec ou pas. Tu as le droit de décider de laisser tous les droits (ça s'appelle du domaine public) mais il faut quand même le préciser dans un fichier de licence.
Et puis licence ou pas, on ne peut pas exclure que certains ne respectent pas les règles. A commencer par Microsoft qui a racheté GitHub, et qui depuis fait parfois un usage statistique des dépôts sans demander l'autorisation.
Pour ma part je recommande quand même l'auto-hébergement, ou si tu ne peux pas le faire chez toi, louer un petit serveur que tu gères toi-même. A priori moins de risque que l'hébergeur vienne mettre le nez dans tes sources que chez GitHub.
Et là tu as le choix total entre rsync, git ou autre logiciel de synchronisation ou de versionnage. Voir un mix des deux, et tu trouveras ensuite bien d'autres modes d'utilisation de ton serveur.

[Obsidian]

Un bémol cependant: ça ne marche qu'avec les fichiers plein texte. Si c'est pour manipuler tes sources, même en Windev (à moins que Windev utilise un encodage que j'ignore) c'est très bien, mais évite quand même de mettre des binaires dans Git, il n'est clairement pas conçu pour ça.

Avec une précision quand même : Git est un système à snapshots : il ré-enregistre le fichier entier s'il change ne serait-ce que d'un octet. Plus précisément, il enregistre l'état du working directory (au moins pour les fichiers marqués) et compare les différentes révisions quand on lui demande de le faire. Il n'enregistre pas directement les deltas dans l'historique (il peut se permettre de le faire, par contre, quand il "packe" les fichiers pour gagner de la place).

Par ailleurs, Git enregistre bien les différentes versions du contenu d'un fichier donné, en se basant sur leur somme SHA1. Ceci implique que si on enregistre un fichier, puis qu'on le modifie d'un octet et qu'on l'enregistre à nouveau, puis qu'on le fait revenir à son état initial et qu'on l'enregistre une troisième fois, on aura bien deux versions différentes enregistrées sur le disque et non trois.

Par conséquent, même si Git n'est pas spécialement fait pour le binaire, la seule chose difficile sera de visualiser les différences, mais ça ne lui posera pas de problème particulier pour enregistrer ces fichiers.

EN REVANCHE : il est important de ne pas s'en servir pour sauvegarder à tout bout de champ l'état d'un très gros fichier. On peut le faire ponctuellement si ça se justifie, mais il faut éviter, par exemple, de commiter les retouches Photoshop que l'on va appliquer à une photo en ultra-haute résolution, par exemple, parce que chacune de ses retouches va être traitée comme une nouvelle photo indépendante pesant le même poids que les autres et là, la taille du dépôt peut exploser.

Par contre, pour le code, on peut vraiment y aller sans se soucier des problèmes de taille avec du matériel moderne : le projet d'application web sur lequel je travaille au boulot occupe 46 Mo après trois ans de développement dessus et le noyau Linux, pour lequel Git a été développé et qui reste de loin, à mon avis, le plus grand projet public géré par Git en terme de contributions, qui sur mon disque contient la branche master, la branche stable, linux-next et plusieurs branches de testing pour le réseau et les cartes sans fil, qui accuse près de 24000 contributeurs et 1044914 (!) commits accessibles sur la seule branche master n'occupe que 4,9 Gio sur ma machine actuellement.

[esperanto]

Avec une précision quand même : Git est un système à snapshots : il ré-enregistre le fichier entier s'il change ne serait-ce que d'un octet. Plus précisément, il enregistre l'état du working directory (au moins pour les fichiers marqués) et compare les différentes révisions quand on lui demande de le faire. Il n'enregistre pas directement les deltas dans l'historique (il peut se permettre de le faire, par contre, quand il "packe" les fichiers pour gagner de la place).

Exact, je l'ai découvert aussi à mon grand étonnement il y a quelques temps. Depuis j'étudie de près les alternatives de type darcs et pijul, dans l'espoir que l'une d'entre elles permette de faire encore mieux que git (qui est des fois casse pieds quand on fait plusieurs fois des rebase au même endroit)
Mais petite question: que se passe-t-il lors d'un push ou d'un pull, est-ce qu'il récupère les fichiers en entier ou seulement les différences?

Par ailleurs, Git enregistre bien les différentes versions du contenu d'un fichier donné, en se basant sur leur somme SHA1. Ceci implique que si on enregistre un fichier, puis qu'on le modifie d'un octet et qu'on l'enregistre à nouveau, puis qu'on le fait revenir à son état initial et qu'on l'enregistre une troisième fois, on aura bien deux versions différentes enregistrées sur le disque et non trois.

Oui mais avec 3 SHA-1 distincts, non? Je suppose qu'il tient compte d'un élément sur lequel l'utilisateur n'a aucun contrôle, la date exacte du commit par exemple, pour garantir l'unicité du SHA-1 dès lors qu'on fait un commit et pas un reset --hard?

[Obsidian]

Exact, je l'ai découvert aussi à mon grand étonnement il y a quelques temps. Depuis j'étudie de près les alternatives de type darcs et pijul, dans l'espoir que l'une d'entre elles permette de faire encore mieux que git (qui est des fois casse pieds quand on fait plusieurs fois des rebase au même endroit)

En quoi est-ce casse-pied ? (vraie question)

Mais petite question: que se passe-t-il lors d'un push ou d'un pull, est-ce qu'il récupère les fichiers en entier ou seulement les différences?

Les deux : Git va télécharger les objets dont il a besoin et qu'il ne possède pas encore. À ce niveau, c'est transparent et il s'agit bien de télécharger un fichier entier mais, ce faisant, le serveur peut transmettre des deltas plutôt que l'intégralité du contenu si son homologue dispose des infos nécessaires pour le reconstruire de l'autre côté. Donc c'est à ce niveau-là qu'on les utilise, plutôt que de construire l'historique entier dessus, ce qui simplifie ÉNORMÉMENT les choses ensuite.

Oui mais avec 3 SHA-1 distincts, non? Je suppose qu'il tient compte d'un élément sur lequel l'utilisateur n'a aucun contrôle, la date exacte du commit par exemple, pour garantir l'unicité du SHA-1

Toute la clé du mystère est là : une somme SHA-1 est forcément unique ! On considère qu'il n'y aura jamais de collision. Certes, faire une surjection d'un ensemble de fichiers de taille arbitraire vers un message d'exactement 20 octets implique forcément des collisions en théorie (et même beaucoup) mais d'un autre côté, 20 octets, ça fait 2¹⁶⁰ combinaisons, ce qui est comparable au nombre d'atomes dans l'univers.

Du coup, la probabilité que ça arrive dans les faits est extrêmement faible et si on voulait le faire exprès, il faudrait encore réussir à produire un fichier de la même taille, donc la probabilité est virtuellement nulle. Enfin, c'est ce qu'on pensait jusqu'à ce que Google arrive à la casser ! Depuis SHA-1 en elle-même commence à être dépréciée, mais le concept de Git tient toujours debout. Il suffit de migrer à une fonction plus forte (sans doute SHA-256).

dès lors qu'on fait un commit et pas un reset --hard?

En fait, Git utilise exactement quatre types d'objet :

• Blob
• Tree
• Commit
• Tag

Dans tous ces cas, un objet sera forcément matérialisé par un fichier dont le nom sera forcément le résultat de la somme SHA-1 de leur contenu (privé des deux premiers caractères hexadécimaux car on les affecte au répertoire qui les contient). Ça permet de les retrouver facilement mais même si on les renommait, leur somme serait automatiquement recalculée à la lecture dont il n'y aurait pas de fraude possible à ce niveau.

- Les Blobs contiennent une suite de données de longueur arbitraire. C'est eux qui sont utilisés pour enregistrer le contenu proprement dit d'un fichier sans l'associer à un nom en particulier ;
- Les Tree sont des arborescences : c'est un fichier au format texte qui contient une liste de noms de fichiers qui, sur chaque ligne, donne le nom et le chemin d'accès complet d'un fichier, ses attributs et l'ID SHA-1 du blob qui recèle son contenu (accessoirement, c'est aussi pour cela qu'on ne peut pas commiter de répertoires vides avec Git) ;
- Les Commit : là encore, un fichier texte qui contient l'ID de l'objet Tree qui correspond à l'état de l'index au moment où on a commité, assorti des informations donnés par l'auteur (la date, le message de log, etc) et s'il y a lieu, une ou plusieurs lignes « Parent: » qui indiquent l'ID SHA-1 de l'objet Commit parent (le précédent dans l'historique) ;
- Les Tags, qui ne servent qu'en cas de tag annoté, pour contenir les méta-informations associées (sinon, les tags sont traités comme des étiquettes ordinaires).

De là, on comprend facilement ce qu'il va se passer :

• Si on initialise un nouveau dépôt, que l'on y crée un fichier « a », que l'on copie ce fichier vers « b », que l'on ajoute ces deux fichiers « a » et « b » avec git add et que l'on commite le tout, on va créer automatiquement trois objets : 1 commit, 1 tree et 1 blob. Le commit contiendra le manifeste de l'utilisateur et une référence vers le tree (qui donnera l'état de l'index à ce moment-là), et ce tree contiendra deux entrées a et b qui, chacune, pointeront le même objet blob ;
• Git n'a pas besoin de « savoir » à l'avance s'il possède déjà un contenu : il calcule la somme SHA-1 de ce qu'il a besoin d'enregistrer, ce qui lui permet de vérifier ensuite facilement s'il le possède déjà ou pas. Et même s'il ne faisait pas la vérification, le fait d'ouvrir un nouveau fichier avec le même nom (la somme SHA-1) écraserait automatiquement le précédent pour le remplacer par un nouveau fichier… au contenu identique ;
• Les tree contiennent les sommes SHA-1 des blobs auxquels ils se réfèrent, et les commits font de même avec les tree. Or, inscrire ces sommes dans leur contenu influe sur leur propre somme, ce qui rend ces objets immuables et surtout : incorruptibles ! Il n'est donc pas possible non plus de casser un historique. Ce que fait Git lors d'un rebase ou d'un reset --hard, c'est déréférencer l'ancien et en reconstruire un neuf à côté.

Concernant ce dernier point, on se rend compte que cela forme en fait une sorte de « blockchain », dont on connaît tous les vertus aujourd'hui, à ceci près que Git est sorti en 2005 et que le bitcoin est apparu en 2009.

Pour l'anecdote, Git est le second gros projet à succès de Linus Torvalds après le noyau Linux. On s'est donc légitimement demandé si le bitcoin ne serait pas tout simplement son troisième :-) Taquin de nature, il aurait entretenu le doute d'un léger « … noooon :-) » du bout de la langue, suggérant le contraire… L'article concluant tout de même que ça restait très peu probable, ne serait-ce que parce que le logiciel du bitcoin est écrit en C++, que Linus a en horreur. :-)

[esperanto]

ce faisant, le serveur peut transmettre des deltas plutôt que l'intégralité du contenu si son homologue dispose des infos nécessaires pour le reconstruire de l'autre côté.

Donc, ta remarque, bien que parfaitement exacte, ne change rien à ce que j'affirmais: même s'il stocke des fichiers entiers, Git permet de ne transmettre sur le réseau que les différences, ce qui est donc plus léger qu'une synchronisation basée uniquement sur la date.
Désolé pour l'auteur de la question, on dérive du sujet initial. Mais passons.

En quoi est-ce casse-pied ? (vraie question)

Je fais beaucoup de rebase et depuis qu'il y a l'option rebase-merges, je n'hésite plus à le faire sur des historiques complexes.
Parfois un conflit apparaît, ok je le résouds. Mais si ensuite je fais de nouveau un rebase depuis le même point, même si je ne fais aucune modification au fichier en conflit, ce conflit revient à chaque fois.
Tu vas me dire qu'il y a l'option rerere (pour le coup on ne peut pas dire que git manque d'originalité pour les noms...) et elle m'aide dans bien des cas, mais elle a encore un inconvénient. Il m'est arrivé de me tromper dans la résolution d'un conflit ; hors rerere, pas de souci, je fais un nouveau rebase et je corrige. Le souci, c'est qu'au prochain rebase, c'est la première correction qui est dans le rr-cache, celle qui était incorrecte. Pour le moment je n'ai pas trouvé comment supprimer un objet du rr-cache sauf à le vider complètement (perdant alors d'autres corrections qui elles étaient pertinentes). Ou comment faire un "amend" dans le rr-cache. Si l'un ou l'autre est possible, je suis intéressé.

Toute la clé du mystère est là : une somme SHA-1 est forcément unique ! On considère qu'il n'y aura jamais de collision.

Alors de deux choses l'une, soit je n'ai pas compris ce que tu écrivais ici

Ceci implique que si on enregistre un fichier, puis qu'on le modifie d'un octet et qu'on l'enregistre à nouveau, puis qu'on le fait revenir à son état initial et qu'on l'enregistre une troisième fois, on aura bien deux versions différentes enregistrées sur le disque et non trois.

soit tu n'as pas compris où je voulais en venir. Alors voici le scénario que j'ai essayé:

1. je crée un dépôt avec un seul fichier
2. je fais une modification dans le fichier puis un commit
3. je fais la modification inverse et un commit

Le fichier aux étapes 1 et 3 est identique, même contenu et même nom. Alors pourquoi le SHA1 est-il différent? Bien sûr j'insiste sur le fait qu'il n'y ait qu'un seul fichier et aucune autre modification dans le dépôt. Donc je suppose que la somme calculée tient compte aussi d'autres critères, la date du fichier ou celle du commit par exemple?

Note : je parle bien du SHA1 qui est visible dans un log. J'ai bien lu les explications que tu donnes plus loin, je comprends que sur les différents types d'objet (commit, blob, tree ou tag) c'est celui du commit qui est visible dans un log.

Cette unicité du SHA1 est en fait parfois problématique. Par exemple quand je fais un cherry-pick, un nouveau SHA1 est généré, distinct de celui du patch initial même si une fois extrait au format diff, le patch correspondant serait strictement identique. Je sais qu'il y a une option pour garder une trace de l'origine d'un commit, mais l'info se trouve dans le commentaire, pas sur la première ligne qui est la seule visible quand je fais défiler le log (avec gitk par exemple). Ennuyeux quand je veux comparer deux branches, savoir quels patches sont issus d'un cherry-pick ou pas. Mais surtout si j'ai entre temps fait un rebase sur la branche initiale, ce commit peut avoir changé de numéro, rendant l'information plus pertinente du tout...

[Obsidian]

Donc, ta remarque, bien que parfaitement exacte, ne change rien à ce que j'affirmais: même s'il stocke des fichiers entiers, Git permet de ne transmettre sur le réseau que les différences, ce qui est donc plus léger qu'une synchronisation basée uniquement sur la date.

Désolé pour l'auteur de la question, on dérive du sujet initial. Mais passons.

Absolument, et on va essayer d'y revenir d'ailleurs. Mais tâchons déjà de trancher cette question (et s'il le faut, je diviserai le fil en deux discussions distinctes).

Je fais beaucoup de rebase et depuis qu'il y a l'option rebase-merges, je n'hésite plus à le faire sur des historiques complexes.
Parfois un conflit apparaît, ok je le résouds. Mais si ensuite je fais de nouveau un rebase depuis le même point, même si je ne fais aucune modification au fichier en conflit, ce conflit revient à chaque fois.
[…] Ou comment faire un "amend" dans le rr-cache. Si l'un ou l'autre est possible, je suis intéressé.

Je ne peux pas t'aider sur ce point car je n'ai pas assez pratiqué « rerere » pour savoir correctement m'en servir. Plus précisément, soit je travaille tout seul (la plupart du temps), sur mes propres projets ou sur les professionnels mais ma compagnie n'étant pas à proprement parler spécialisé dans le développement, je suis souvent le seul programmeur impliqué sur une tâche donnée, soit je contribue ponctuellement à de grands projets en envoyant des patches, bien ficelés mais pour des tâches qui n'ont jamais justifié la création d'une branche (sauf en local, mais là encore, pas suffisamment longtemps pour avoir besoin de la rebaser trop souvent).

Je suppose qu'en effet, il doit y avoir moyen d'amender le contenu de rr-cache, même si ce n'est pas orthodoxe. Je reviendrai poster ici si je trouve une solution satisfaisante de mon côté.

1. je crée un dépôt avec un seul fichier
2. je fais une modification dans le fichier puis un commit
3. je fais la modification inverse et un commit

Le fichier aux étapes 1 et 3 est identique, même contenu et même nom. Alors pourquoi le SHA1 est-il différent? Bien sûr j'insiste sur le fait qu'il n'y ait qu'un seul fichier et aucune autre modification dans le dépôt. Donc je suppose que la somme calculée tient compte aussi d'autres critères, la date du fichier ou celle du commit par exemple?

Note : je parle bien du SHA1 qui est visible dans un log. J'ai bien lu les explications que tu donnes plus loin, je comprends que sur les différents types d'objet (commit, blob, tree ou tag) c'est celui du commit qui est visible dans un log.

Tout-à-fait. Comme tu l'as dit, c'est bien la somme SHA1 du commit qui apparaît dans le log et qui correspond aux révisions. Et tu as bien fait deux commits distincts dans le temps : l'un pour enregistrer une première fois ton fichier (après l'avoir modifié mais Git ne le sait pas), et un seconde fois pour annuler cette modification.

En outre, tu as bien enregistré ton fichier deux fois, mais jamais dans son état initial (le premier commit a enregistré ton fichier après qui tu lui aies apporté une modification). Donc même en développant le contenu de l'objet pour vérifier celui des autres objets référencés, tu ne trouveras jamais deux fois la même référence non plus. Il aurait fallu faire un commit au point n° 1 pour cela.

Cette unicité du SHA1 est en fait parfois problématique. Par exemple quand je fais un cherry-pick, un nouveau SHA1 est généré, distinct de celui du patch initial même si une fois extrait au format diff, le patch correspondant serait strictement identique. Je sais qu'il y a une option pour garder une trace de l'origine d'un commit, mais l'info se trouve dans le commentaire, pas sur la première ligne qui est la seule visible quand je fais défiler le log (avec gitk par exemple).

Absolument, mais comme indiqué, il ne s'agit pas d'un identifiant « fongible » comme pourrait l'être l'ID de la clé primaire d'une table dans une base de données, par exemple. C'est bien parce que le commit contient des informations différentes (à commencer par l'heure, mais aussi et surtout le commit parent, référence qui de proche en proche finit par matérialiser la branche) que cette somme diffère. Et d'ailleurs, même si tu supprimes l'ancienne branche, les objets persisteront quelque temps (typiquement trois mois) avant d'être éliminés par le garbage collector. Si bien que si tu te réfères à l'ancien commit, tu vas également retrouver l'ancienne branche. Mais bon, je suppose que tu le sais déjà.

Ennuyeux quand je veux comparer deux branches, savoir quels patches sont issus d'un cherry-pick ou pas. Mais surtout si j'ai entre temps fait un rebase sur la branche initiale, ce commit peut avoir changé de numéro, rendant l'information plus pertinente du tout...

Je vois de quoi tu veux parler, mais cela n'a jamais été un problème de mon côté : le titre est en général bien plus pertinent et surtout, comme indiqué dans la doc de l'option « -x », ça n'est utile que si tu restes en privé. Dès que tu publies ta branche, les informations en question deviennent sans objet pour les autres protagonistes.

Cela dit, tel que Git est construit, ça ne devrait pas être très difficile d'écrire une extension pour le faire. Soit en ajoutant automatiquement sa forme raccourcie au titre de ton commit pour ne pas avoir à le faire à la main, soit en ajoutant une ligne aux méta-données du commit et en ajoutant une option « % » à git log pour les afficher avec --pretty…

[esperanto]

Plus précisément, soit je travaille tout seul (la plupart du temps), sur mes propres projets ou sur les professionnels

Moi aussi je travaille souvent seul, en fait quand ce n'est pas le cas je ne me permettrais pas de faire un rebase et un push --force sauf sur une branche dont je suis le seul utilisateur.
Quand on travaille à plusieurs, on fait beaucoup de merge mais rarement des rebase sauf sur des feature branches privées.

Je suppose qu'en effet, il doit y avoir moyen d'amender le contenu de rr-cache, même si ce n'est pas orthodoxe. Je reviendrai poster ici si je trouve une solution satisfaisante de mon côté.

Pourquoi pas orthodoxe ? Le rr-cache est de toute façon local, et il n'est là que pour te rappeler les corrections que tu as déjà faites, ce sont des suggestions que tu n'es pas obligé de suivre.

Bon, finalement j'ai trouvé deux possibilités: il semble bien y avoir une commande 'rerere forget', et même un script 'rerere-train' qui essaie de rejouer tout l'historique juste pour pouvoir reconstituer un rr-cache correct en partant de l'hypothèse que si un 'merge commit' contient un conflit, alors celui qui se trouve actuellement dans l'historique contient la solution.
J'ai essayé rapidement, pour le moment ça semble laborieux et peu convaincant.
Et puis en testant sur un dépôt que j'utilise beaucoup, je suis encore tombé sur un autre cas: des fichiers où git a réussi à fusionner sans détecter de conflit, mais ensuite j'ai dû corriger des erreurs à la main (fichiers qui ne compilent pas). Dans ce cas, rr-cache ne mémorise rien (git ne sait pas que la fusion s'est mal passée) et l'erreur revient quand même à chaque rebase...

Là où c'est ennuyeux, c'est quand on sait que le rebase que je fais n'a rien à voir avec les fichiers en conflit: simplement, comme un rebase consiste à rejouer tout l'historique après le point de modification, git refait les mêmes erreurs.
D'où mon intérêt pour les VCS orientés changeset, type darcs ou pijul, même si pour le moment j'en suis au stade de l'expérimentation.
Dans pijul, l'ordre des commits est seulement partiel: si je veux modifier un commit au milieu de l'historique, je n'ai pas forcément à rejouer tout ce qui suit - seulement les commits qui ont une dépendance avec celui que je modifie, parce qu'ils font une modification sur les mêmes fichiers et à un endroit proche. Et donc pas besoin de résoudre le même conflit à chaque fois, sauf si bien sûr le commit qui contient le merge a une dépendance sur mes modifications - l'exception, pas la règle. Bon, pour le moment pijul semble refuser d'amender un commit s'il y a des dépendances, donc je suis obligé de faire ça à la main, mais je crois qu'on pourrait aboutir au final à l'équivalent d'un rebase partiel (ne rejouant que les commits dépendant de celui que tu modifies). Et en pratique, peu de commits ont des dépendances. Affaire à suivre.

Je vois de quoi tu veux parler, mais cela n'a jamais été un problème de mon côté : le titre est en général bien plus pertinent et surtout, comme indiqué dans la doc de l'option « -x », ça n'est utile que si tu restes en privé. Dès que tu publies ta branche, les informations en question deviennent sans objet pour les autres protagonistes.

Oui le titre est pertinent si ton but est de savoir dans quel commit tu as implémenté telle ou telle chose; mais parfois j'essaie de comparer des branches, par exemple savoir si j'ai implémenté la même solution en dev et en prod. Avec un VCS orienté changeset, le numéro sera identique sauf si il y a eu un conflit lors du cherry-pick. Avec git je n'ai en effet que l'option -x, mais l'info qu'elle donne devient obsolète en cas de rebase.

[wd_newbie]

Bonjour,

je ne suis pas certain ... d'avoir tout compris les propos du suivi du post ... je n'en suis pas là ... mais la lecture a été intéressante

Mais vous m'avez convaincu, et en utilisant git / github avec VS Code, c'est juste génial, j'ai réussi a créer les synchros entre mes différentes machines

Une remarque, depuis quelques temps, il est possible de bénéficier de repository privés gratuitement sur Github

Une dernière question : est-il possible de limiter le nombre de commit archivés ? Comme je risque d'en faire ± 1-2 jour pour la synchro, je n'ai pas vraiment besoin de garder des dizaines de commit archivés

[Obsidian]

je ne suis pas certain ... d'avoir tout compris les propos du suivi du post ... je n'en suis pas là ... mais la lecture a été intéressante
Mais vous m'avez convaincu, et en utilisant git / github avec VS Code, c'est juste génial, j'ai réussi a créer les synchros entre mes différentes machines

Heureux de savoir que tu aies pu finalement y parvenir par toi même !
Et pour le reste, en effet : Git est souvent surprenant de prime abord, mais se révèle souvent être le meilleur modèle sur le long terme.

Une dernière question : est-il possible de limiter le nombre de commit archivés ? Comme je risque d'en faire ± 1-2 jour pour la synchro, je n'ai pas vraiment besoin de garder des dizaines de commit archivés

Qu'appelles-tu « commit archivé » ? Tu n'as pas spécialement besoin de faire de commit pour synchroniser des machines. Tu ne le fais que si tu apportes des modifications à ton dépôt.

Si toutefois tu veux dire que tu penses que toutes ces fusions vont générer du « bruit » inutile que l'on ne veut pas garder dans l'historique final, alors oui. Pour cela, on travaille en général sur une branche distincte, que l'on finit par reconstruire à la fin soit en la rebasant (généralement en mode interactif avec -i), soit en en ouvrant une autre au propre à côté et en sélectionnant uniquement les modifications qui nous intéressent avec cherry-pick. On finit par fusionner cette branche dans le tronc principal et on abandonne l'ancienne. Les commits qu'elle contient ne sont alors plus visibles et c'est le garbage collector qui les éliminera du disque en temps voulu.

[esperanto]

je ne suis pas certain ... d'avoir tout compris les propos du suivi du post ... je n'en suis pas là ... mais la lecture a été intéressante

Oui désolé la discussion a un peu dérivé, tu peux te concentrer sur les deux premières réponses le reste c'était un peu entre nous

Une dernière question : est-il possible de limiter le nombre de commit archivés ?

Pas directement, le serveur stocke tout. Mais ce que tu peux faire:

• Utiliser l'option clone --depth pour ne pas récupérer tout l'historique localement. Mais cette commande, tu la feras une seule fois par machine donc ça ne changera pas grand chose ensuite
• Tant que tu n'as pas fait de push, tu peux utiliser commit --amend pour corriger le dernier commit plutôt que d'en créer un de plus
• Tant que tu n'as pas fait de push, tu peux même réécrire l'historique, c'est la commande rebase dont nous discutions plus haut. Mais ça demande bien plus d'expérience pour ne pas faire d'erreurs.

Idéalement, essaie de faire:

• un commit par fonctionnalité, avec un titre explicite (tu verras, un jour tu seras bien content de trouver où et comment tu avais implémenté tel truc)
• uniquement des commits qui compilent (quitte à corriger avec un --amend jusqu'à ce que ça marche). J'ai déjà eu le cas une fois d'un collègue qui avait fait un commit foireux et tout le monde a été bliqué pendant plusieurs jours (bon c'était pas encore avec Git, mais je préfère quand même garder ça en tête)

[wd_newbie]

Je pense que je vais utiliser le commit --amend pour mes commit de "synchronisation" entre mes machines et un "normal" quand telle ou telle fonction est OK et compile

Je pense que ça va faire le taff que je demande.

Je passe en résolu

Un grand merci pour votre aide précieuse