Ok that sort of makes sense, but for example in the case of the XHCI patch, the merge conflict appears to be that since soc/intel/denverton_ns/xhci.c was changed completely to reflect the usage of the common code and shouldn't cause an issue with being cherry-picked onto master.......
So, I just tried it and see that it comes up with the merge conflict. I guess the merge operation is super-cautious and prefers the developer to do a manual merge vs always accepting the newer code? Is there a setting that can be modified for that? Having to do a merge resolution for wholesale changes to code seems counter-productive.
Next question would be, what's the best mechanism to do this and not mess up my patch train again. I want to keep all the relationships in gerrit so the progression can be visualized. I have a clean master branch and the denverton_refactor branch locally where I'm keeping my changes. I'd like to keep it in denverton_refactor locally..... is it required that I need to apply the merge resolution commit on the master branch or can I rewind my branch to the offending commit^ and do git pull --rebase at that point?
-----Original Message----- From: Paul Menzel pmenzel@molgen.mpg.de Sent: Wednesday, January 12, 2022 10:06 AM To: coreboot@coreboot.org Subject: [coreboot] Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)
Caution: This is an external email. Please take care when clicking links or opening attachments.
Dear Jeff,
Am 12.01.22 um 15:49 schrieb Jeff Daly:
Ok, so what I've figured out is that it seems gerrit doesn't like it when the code gets refactored. I have several commits that are showing merge conflicts but the files that have conflicts are because a lot of code changes between them as things get refactored. Entire blocks of code in some files are removed, some files are just completely replaced with newer files that have the correct content in them. I'd hate to have to do something dumb like rename the files that have too many changes for gerrit/git to figure out. CB:61015 is a perfect example. Soc/intel/denverton_ns/soc_util.c was changed to delete functions from colliding with others in the SoC common code (or were just plain unnecessary). The change deletes get_tseg_memory(), get_top_of_low_memory(), get_top_of_upper_memory(). No other changes other than deletions and I'm getting a merge conflict. Either I'm dumb or something else is dumb. (and I have been dumb before, so maybe it's me but this one seems kinda obvious unless there's some setting someplace that complains when there's more than a few lines difference).
It is my understanding, that Gerrit displays *Merge Conflict* on a change-set, if the change-set itself cannot be directly be cherry-picked on top of the master branch. So, everything is fine with your change-set, and to be applied to the master branch, the parent changes (from your branch) need to be applied first.
Kind regards,
Paul _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org