Ik heb als 'erfenis' een git repository gekregen met daarin twee branches. Laten we ze voor het gemak even productie en development noemen.
In 2017 is development geforkt van productie, tot 2017 loopt de history dus gelijk.
Daarna zijn tussen 2017 en nu zo'n 1500 commits gedaan op productie, voornamelijk bugfixes.
Helaas is er voor gekozen om die commits niet te mergen/cherrypicken of development te fast-forwarden, maar dezelfde wijzigingen los toe te passen. Resultaat is dus dubbele commits met een eigen hash.
Op dezelfde manier zijn er wijzigingen van development naar productie en van productie naar development gekopiëerd. Dit zijn zowel wijzigingen als bestanden die zijn verwijderd.
Het eindresultaat is dat de histories vanaf 2017 dus niet meer matchen. Bij een merge gaat een deel goed, maar er blijven zo'n 900 merge conflicts over, veelal wijzigingen die dus al zijn toegepast.
De wijzigingen zijn 1:1 hetzelfde, met dezelfde commit message, vaak zelfs binnen enkele minuten van elkaar, alleen een andere hash. Ook is het doel om de history van development gelijk te trekken aan productie, dus in principe een kwestie van 'overal rechts', maar ook dit krijg ik niet voor elkaar. Gezien de vele conflicts loopt menig merge tool volledig vast.
Is er een manier om dit op te lossen? Is er een tool die bijvoorbeeld deze commits kan vergelijken, en ondanks dat de hash niet gelijk is kan zien dat ze wel bij elkaar horen, in feite dus mergen zonder naar commit hashes te kijken?
Het enige dat ik heb gevonden/geprobeerd zijn de normale processen, dus mergen of rebasen. In alle gevallen krijg ik die honderden merge conflicts, die wil ik graag automatisch oplossen, maar daarover kan ik helemaal geen informatie vinden.
In 2017 is development geforkt van productie, tot 2017 loopt de history dus gelijk.
Daarna zijn tussen 2017 en nu zo'n 1500 commits gedaan op productie, voornamelijk bugfixes.
Helaas is er voor gekozen om die commits niet te mergen/cherrypicken of development te fast-forwarden, maar dezelfde wijzigingen los toe te passen. Resultaat is dus dubbele commits met een eigen hash.
Op dezelfde manier zijn er wijzigingen van development naar productie en van productie naar development gekopiëerd. Dit zijn zowel wijzigingen als bestanden die zijn verwijderd.
Het eindresultaat is dat de histories vanaf 2017 dus niet meer matchen. Bij een merge gaat een deel goed, maar er blijven zo'n 900 merge conflicts over, veelal wijzigingen die dus al zijn toegepast.
De wijzigingen zijn 1:1 hetzelfde, met dezelfde commit message, vaak zelfs binnen enkele minuten van elkaar, alleen een andere hash. Ook is het doel om de history van development gelijk te trekken aan productie, dus in principe een kwestie van 'overal rechts', maar ook dit krijg ik niet voor elkaar. Gezien de vele conflicts loopt menig merge tool volledig vast.
Is er een manier om dit op te lossen? Is er een tool die bijvoorbeeld deze commits kan vergelijken, en ondanks dat de hash niet gelijk is kan zien dat ze wel bij elkaar horen, in feite dus mergen zonder naar commit hashes te kijken?
Het enige dat ik heb gevonden/geprobeerd zijn de normale processen, dus mergen of rebasen. In alle gevallen krijg ik die honderden merge conflicts, die wil ik graag automatisch oplossen, maar daarover kan ik helemaal geen informatie vinden.