Git branches met niet-matchende histories fixen

[Oon]

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.

[keken]

Kan je niet beter een nieuwe develop branch maken vanaf master? Eventueel cherry pick je dan nog wijzigingen vanaf de oude develop branch naar de nieuwe.

[Voor 4% gewijzigd door keken op 09-02-2022 07:57]

[CodeCaster]

https://stackoverflow.com...rsion-of-git-merge-s-ours

code:

git checkout development
git merge -X theirs production

[Oon]

keken schreef op woensdag 9 februari 2022 @ 07:57:
Kan je niet beter een nieuwe develop branch maken vanaf master? Eventueel cherry pick je dan nog wijzigingen vanaf de oude develop branch naar de nieuwe.

Development loopt flink wat voor op productie, dus dan zouden we inderdaad alsnog flink wat moeten cherrypicken. Helaas niet een keuze die ik zomaar kan maken, maar dat zou als het niet anders kan wel een optie zijn

[418O2]

Production renamen naar production_legacy, nieuwe production/main branch forken vanaf develop.

Burning bridges. Waarom zou je al die moeite doen? Als je develop branch klopt zou ik daar vanaf verder gaan

[Oon]

418O2 schreef op woensdag 9 februari 2022 @ 08:21:
Production renamen naar production_legacy, nieuwe production/main branch forken vanaf develop.

Burning bridges. Waarom zou je al die moeite doen? Als je develop branch klopt zou ik daar vanaf verder gaan

Als het mijn eigen persoonlijke repository was had ik dat gedaan, maar in dit geval zoek ik toch echt een oplossing om het binnen de bestaande branches te doen

[418O2]

Oon schreef op woensdag 9 februari 2022 @ 08:40:
[...]

Als het mijn eigen persoonlijke repository was had ik dat gedaan, maar in dit geval zoek ik toch echt een oplossing om het binnen de bestaande branches te doen

Ik heb ditzelfde niet lang geleden ook gehad, ik wou mijn vingers niet branden aan mogelijk verschillen... De defenitie van "gelijke commits" is bijvoorbeeld al interpretatie.

[Oon]

CodeCaster schreef op woensdag 9 februari 2022 @ 08:06:
https://stackoverflow.com...rsion-of-git-merge-s-ours

code:

git checkout development
git merge -X theirs production

Dit nu net geprobeerd (maar dan ours ipv theirs) en daarmee hou ik nog zo'n 400 conflicts over, maar dat lijken bijna allemaal deletions te zijn die aan beide kanten worden gedaan of commits in bestanden die blijkbaar daarna ook zijn verwijderd..

Scheelt in ieder geval al meer dan de helft

[eamelink]

Ik zou één branch squashen naar één commit bovenop de shared parent en die dan mergen. Dan ben je alle tussenliggende conflicten kwijt.

[ThomasG]

eamelink schreef op woensdag 9 februari 2022 @ 08:50:
Ik zou één branch squashen naar één commit bovenop de shared parent en die dan mergen. Dan ben je alle tussenliggende conflicten kwijt.

Dit kun je trouwens in één keer doen met git merge --squash [branch].