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
