Après, je ne sais pas si en pratique cela s'avérera d'un grand intérêt et plus souple à l'usage que l'existant, mais la théorie qu'il y a derrière est jolie. Elle est expliquée plus en détail dans ces deux articles de blogs :
Merci pour ces références! Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles – il faut se souvenir que GIT ne sauvegarde pas les résolutions de conflit – à moins d'un paramétrage spécial. C'est gênant lorsqu'on travaille sur l'historique, par exemple, dans les rebase complexes où figurent des résolutions de conflit, que git demande de résoudre à nouveau. Par ricochet cela rend inutilement pénible la fusion de deux dépôts GIT, puisque l'approche bébête consistant à importer (fetch) une deuxième historique COMMIT-0 ... { historique complexe ... } COMMIT-1 puis à faire un cherry-pick de COMMIT-0 sur la tête de la vieille historique puis un rebase de COMMIT-0..COMMIT-1 ne marche pas. Le problème peut être résolu grâce au filter tree mais c'est bien plus compliqué à mettre en œuvre et incroyablement lent. (J'en ai récemment fait un de 12h sur une historique assez modeste, 4 ans et équipe de 4 à 8 personnes.)
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2. Dernière modification le 19 septembre 2017 à 23:50.
Merci pour ces références! Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles – il faut se souvenir que GIT ne sauvegarde pas les résolutions de conflit – à moins d'un paramétrage spécial. C'est gênant lorsqu'on travaille sur l'historique, par exemple, dans les rebase complexes où figurent des résolutions de conflit, que git demande de résoudre à nouveau. Par ricochet cela rend inutilement pénible la fusion de deux dépôts GIT, puisque l'approche bébête consistant à importer (
fetch) une deuxième historiqueCOMMIT-0 ... { historique complexe ... } COMMIT-1puis à faire uncherry-pickdeCOMMIT-0sur la tête de la vieille historique puis unrebasedeCOMMIT-0..COMMIT-1ne marche pas. Le problème peut être résolu grâce au filter tree mais c'est bien plus compliqué à mettre en œuvre et incroyablement lent. (J'en ai récemment fait un de 12h sur une historique assez modeste, 4 ans et équipe de 4 à 8 personnes.)