Pas de réécriture de l'historique, comme en compta, on ne supprime pas ses erreurs, on les corrige, chaque action de correction laisse une trace dans la timeline (je déteste git rebase perso)
Git, son utilisation est bien trop complexe et les risques de perdre du taf trop importants.
Depuis que j’ai découvert son existence, j’ai toujours trouvé Fossil intéressant sur le principe mais n’ai jamais vraiment appris à m’en servir. Pourtant les tickets distribués avec le répo de code, je trouve le principe excellent. Mais, ce que tu écris ci-dessus est une limitation qui fait que je n’imagine pas l’utiliser un jour. Je ne comprends pas comment tu peux ne pas aimer le rebase et trouver que les risques de perdre du taf trop importants avec Git en même temps. Le rebase, c’est justement ce qui fait qu’en codant, dès que j’ai touché à plus de 10 lignes, j’enregistre un commit. Ce commit n’a pas vocation à durer, mais à m’assurer que je peux revenir à cet état facilement. Une fois que j’ai une fonctionnalité qui marche (ou du moins le crois-je) je regroupe les commits en opérations unitaires liées par la logique (et si j’ai touché d’autres trucs à côté pour me faciliter les tests, je les enlève des commits). J’ajoute des descriptions et j’ai une séquence de commits qui correspondent chacun à un patch le plus indépendant possible des autres et dont l’impact sur le code est clair.
J’ai donc des sauvegardes permanentes de mon code, y compris des commentaires personnels que je ne compte jamais partager, et un historique de développement clair. Comment faire cela sans rebase ?
De plus, en committant tout tout le temps, on se met bien à l’abris des fausses manips, même des "git reset --hard" malencontreux au milieu d'un rebase en cours se retracent finalement bain avec "git reflog".
Bon, comme tu le vois, j’aime bien Git. Mais mon commentaire est surtout là pour que tu m’aides à identifier comment je pourrais modifier ma manière de faire si je voulais utiliser Fossil, pas pour te dire combien Git est mieux. Concrètement, avec Fossil, tu travailles comment ?
[^] # Re: Fossil
Posté par jyes . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 4.
Depuis que j’ai découvert son existence, j’ai toujours trouvé Fossil intéressant sur le principe mais n’ai jamais vraiment appris à m’en servir. Pourtant les tickets distribués avec le répo de code, je trouve le principe excellent. Mais, ce que tu écris ci-dessus est une limitation qui fait que je n’imagine pas l’utiliser un jour. Je ne comprends pas comment tu peux ne pas aimer le rebase et trouver que les risques de perdre du taf trop importants avec Git en même temps. Le rebase, c’est justement ce qui fait qu’en codant, dès que j’ai touché à plus de 10 lignes, j’enregistre un commit. Ce commit n’a pas vocation à durer, mais à m’assurer que je peux revenir à cet état facilement. Une fois que j’ai une fonctionnalité qui marche (ou du moins le crois-je) je regroupe les commits en opérations unitaires liées par la logique (et si j’ai touché d’autres trucs à côté pour me faciliter les tests, je les enlève des commits). J’ajoute des descriptions et j’ai une séquence de commits qui correspondent chacun à un patch le plus indépendant possible des autres et dont l’impact sur le code est clair.
J’ai donc des sauvegardes permanentes de mon code, y compris des commentaires personnels que je ne compte jamais partager, et un historique de développement clair. Comment faire cela sans rebase ?
De plus, en committant tout tout le temps, on se met bien à l’abris des fausses manips, même des "git reset --hard" malencontreux au milieu d'un rebase en cours se retracent finalement bain avec "git reflog".
Bon, comme tu le vois, j’aime bien Git. Mais mon commentaire est surtout là pour que tu m’aides à identifier comment je pourrais modifier ma manière de faire si je voulais utiliser Fossil, pas pour te dire combien Git est mieux. Concrètement, avec Fossil, tu travailles comment ?