问题
This is followup question to this one. We are trying to do upstream merges with stable releases of this project. According to developers of it, they create stable branches from master and then cherry-pick ongoing fixes into the stable. Sounds reasonable strategy, however each time we try to merge with newer stable release it is proven to be a nightmare taking weeks to accomplish. Aside our changes we do on top of current stable branch we are using, even merge between two clean stable vanilla branches result in thousands of "modified" files and hundreds if not thousands of conflicts. We tried two approaches, merge newer stable into our branch, and add our changes only to newer stable release. In both cases the result is the same hundreds of conflicting files.
Example:
Lets checkout one of stable branches (20.4.4.18) from the repogit checkout -b wip001 1a1becf0
Now lets pretend we did some changes (in fact the repo is unchanged) and after some time we want to get latest stable (20.12.5.14) into our wip001 branchgit merge 32fd4a54
We got a changelist of over 9k files, and 156 unresolved conflicts. How come that with zero changes to the old stable there is so much changes? Are they completely messing up the git history? How? What would be the right approach to work with such a repo? We cant merge newer stables into our code since it ends up with conflicts like "ours - modified, theirs - deleted", when the file nor modified, neither deleted in both branches. So I'm thinking about replaying our changes each time on top of the new stable we choose as proposed here.Not sure it would work as intended.
Any help/thoughts is appreciated.
来源：https://stackoverflow.com/questions/65717289/git-whats-wrong-with-git-history-in-this-project-and-how-to-upstream-merge-wit