Merci pour ces réponses, ça à l'air effectivement intéressant.
Il est vrai que git rerere ne marche pas toujours comme on le veut mais personnellement il assez rare que j'en ressente le besoin même dans un projet multi-personne. Si il y a deux évolutions majeures et assez longues à développer en parallèle qui vont toucher une même partie du code, on va réfléchir et s'organiser pour découper ça en plusieurs sous taches avec des dépendances entre elles et intégrer au plus tôt.
Meme sur un projet open source que je contrôle pas, si je sais que je vais casser une partie important de l'architecture/code, je vais commencer par une RFC/RequestForComment avant de me lancer dedans et je vais devoir réfléchir encore plus à découper mon travail en plusieurs changement indépendant intégrable au fil de l'eau.
Effectivement ici j'adapte mon workflow de travail à l'outil (petit commit régulier, intégrer le plus tôt possible par rapport à un gros commit intégré en mode big bang, ceci afin d'éviter les conflits).
Mais ce mode de fonctionnement actuelle me convient bien et convient bien aux équipes avec lequel j'ai travaillé.
J'ai vraiment du mal à m'imaginer si je changerai ma manière de travail avec darcs/pijul ou pas.
En soit si y deux branches qui divergence trop longtemps, le risque est grand de tomber dans un cas où il n'a pas de résolution automatique possible sans un choix fonctionnel et donc une décision humaine et donc je continuerai très certainement à utiliser mon fonctionnement actuel (petit commit, rebase régulier).
[^] # Re: Sympa
Posté par Tangi Colin . En réponse au journal Pijul, version 1.0 en approche. Évalué à 1.
Merci pour ces réponses, ça à l'air effectivement intéressant.
Il est vrai que git rerere ne marche pas toujours comme on le veut mais personnellement il assez rare que j'en ressente le besoin même dans un projet multi-personne. Si il y a deux évolutions majeures et assez longues à développer en parallèle qui vont toucher une même partie du code, on va réfléchir et s'organiser pour découper ça en plusieurs sous taches avec des dépendances entre elles et intégrer au plus tôt.
Meme sur un projet open source que je contrôle pas, si je sais que je vais casser une partie important de l'architecture/code, je vais commencer par une RFC/RequestForComment avant de me lancer dedans et je vais devoir réfléchir encore plus à découper mon travail en plusieurs changement indépendant intégrable au fil de l'eau.
Effectivement ici j'adapte mon workflow de travail à l'outil (petit commit régulier, intégrer le plus tôt possible par rapport à un gros commit intégré en mode big bang, ceci afin d'éviter les conflits).
Mais ce mode de fonctionnement actuelle me convient bien et convient bien aux équipes avec lequel j'ai travaillé.
J'ai vraiment du mal à m'imaginer si je changerai ma manière de travail avec darcs/pijul ou pas.
En soit si y deux branches qui divergence trop longtemps, le risque est grand de tomber dans un cas où il n'a pas de résolution automatique possible sans un choix fonctionnel et donc une décision humaine et donc je continuerai très certainement à utiliser mon fonctionnement actuel (petit commit, rebase régulier).