Ah right. Too many changes to keep track of in my head. I guess that's what good tools are for. In any case, as long as the commits are in small enough bits for reviewers to check in the context of the refactoring I'm doing then it shouldn't matter. I should done soon, pushing the remaining changes to the mainboards and adding my own platforms should be the end of it.
-----Original Message----- From: Nico Huber nico.h@gmx.de Sent: Wednesday, January 12, 2022 12:28 PM To: Jeff Daly jeffd@silicom-usa.com; Paul Menzel pmenzel@molgen.mpg.de; coreboot@coreboot.org Subject: Re: [coreboot] Re: 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.
On 12.01.22 18:11, Jeff Daly wrote:
If I don't have to do anything, then I won't. I wasn't sure whether commits that are marked with conflicts tend to get less attention than ones that don't. I've been rebasing for amending earlier commits so I guess at least I'm doing that correctly. What I'm confused with is as you said, if I'm removing lines it will try to remove them, and fail if something changed between the 2 bases. I'm the only one making any changes, so that shouldn't be an issue. I understand the file replacement explanation as well, but again nothing changed in the file in the base I'm working on and by rebasing against master before pushing, I'd see the merge conflict. If my change got in before someone elses, then they'd see the merge conflict when they went to push.
The xHCI patch on Gerrit is currently based on one changing the PCI ID macro in `xhci.c`. When you cherry-pick the xHCI commit alone (on master where the macro name didn't change), the file contents are different.
Nico
-----Original Message----- From: Nico Huber nico.h@gmx.de Sent: Wednesday, January 12, 2022 12:04 PM To: Jeff Daly jeffd@silicom-usa.com; Paul Menzel pmenzel@molgen.mpg.de; coreboot@coreboot.org Subject: Re: [coreboot] Re: 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.
On 12.01.22 16:21, Jeff Daly wrote:
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?
I don't know any setting to change that. It's simple tools, AFAICT. If you supply them a patch with something to remove they'll try to find the respective line to remove and fail if that line changed between the two bases. Git cannot see that the intention is to replace the entire file no matter its current contents. To a human that might be obvious but also only in the context of your whole patch train. IMO that's correct behavior. For instance, if somebody else added something to that file in the meantime, would the intention still be to replace the whole file? How to decide that automatically?
Having to do a merge resolution for wholesale changes to code seems counter-productive.
You don't have to do anything unless you want to re-organize your patch train. For instance, change the order of commits you currently have on one branch. But is that really what you want?
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?
I'm afraid I don't follow. What is it that you want to do that results in the conflict in the first place?
Generally our Gerrit setup doesn't allow merge commits. If you want to amend a commit on your branch, you have to rebase.
But a `git pull --rebase` would rebase on top of upstream (I assume). That's sometimes useful, but rather a potential cause of conflicts than a resolution.
Nico