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.
-----Original Message----- From: Nico Huber <nic...@gmx.de> Sent: Wednesday, January 12, 2022 12:04 PM To: Jeff Daly <je...@silicom-usa.com>; Paul Menzel <pmen...@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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
