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 <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
