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 <pmen...@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-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
